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Avant-propos 


Utiliser les exemples de code 

Ce livre a comme objectif de vous aider. En règle générale, vous pourrez utiliser 
sans restriction les exemples de code de cet ouvrage dans vos programmes et vos 
documentations. Vous n’avez pas besoin de nous contacter pour une autorisation, à 
moins que vous ne vouliez reproduire des portions significatives de code. La conception 
d’un programme reprenant plusieurs extraits de code de cet ouvrage ne requiert 
aucune autorisation. Par contre, la vente et la distribution d’un CD-ROM d’exemples 
provenant des ouvrages O’Reilly en nécessitent une. Répondre à une question en 
citant le livre et les exemples de code ne requiert pas de pennission. Par contre 
intégrer une quantité significative d’exemples de code extraits de ce livre dans la 
documentation de vos produits en nécessite une. 

Nous apprécions, sans l’imposer, la citation de la source de ce code. Une citation 
comprend généralement le titre, l’auteur, l’éditeur et le numéro ISBN. Par exemple, 
« Programmer efficacement en C++, de Scott Meyers (Dunod). Copyright 2016 Dunod 
pour la version française 978-2-10-074391-9, et 2015 Scott Meyers pour la version 
d’origine 978-1-491-90399-5 ». 

Si vous pensez que l’utilisation que vous avez faite de ce code sort des limites d’une 
utilisation raisonnable ou du cadre de l’autorisation ci-dessus, n’hésitez pas à nous 
contacter à l’adresse permissions@oreilly.com. 


Commentaires et questions 

Adressez vos commentaires et questions concernant ce livre à : 
infos@dunod . com 


Remerciements 


© 


C’est en 2009 que nous avons commencé à enquêter sur ce qui s’appelait alors 
C++0x (le C++ 11 naissant). Nous avons posté de nombreuses questions sur le 
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groupe Usenet comp.std.c++, et nous sommes reconnaissants envers les membres 
de cette communauté (notamment Daniel Krügler) pour leurs réponses très utiles. 
Plus récemment, nous avons confié à Stack Overflow nos interrogations sur C++1 1 et 
C++ 14, et nous sommes tout aussi redevables à cette communauté pour son aide sur 
notre compréhension des plus petits détails du C++ moderne. 

En 2010, nous avons préparé du contenu pour un cours sur C++0x (publié ensuite 
sous le titre OverView of the New C++, Artima Publishing, 2010). L’ensemble de 
ce contenu et mes connaissances ont largement bénéficié du travail d’investigation 
effectué par Stephan T. Lavavej, Bernhard Merkle, Stanley Friesen, Leor Zolman, 
Hendrik Schober et Anthony Williams. Sans leur aide, nous n’aurions probablement 
jamais été en mesure d’écrire Effective Modem C++. Ce titre a été suggéré ou approuvé 
par plusieurs lecteurs en réponse à notre billet du 18 février 2014, « Help me name my 
book » (http://scottmeyers.blogspot.com/20 14/02/helpmiemame'my 'book.html). Endrei 
Alexandrescu (auteur de l’ouvrage Modem C++ Design, Addison-Wesley, 2001) a été 
très aimable de cautionner ce titre, qui reprend en partie ses termes. 

Nous ne sommes pas en mesure de donner l’origine de toutes les informations présentées 
dans cet ouvrage, mais certaines sources ont eu une influence directe. Au conseil 4, 
l’utilisation d’un template indéfini pour forcer le compilateur à fournir une information 
de type a été suggérée par Stephan T. Lavavej, et Matt P. Dziubinski nous a indiqué 
Boost. Type Index. Au conseil 5, l’exemple unsigned std: : vector<int>: :size_type est 
extrait de l’article publié le 28 février 2010 par Andrey Karpov, « In what way can 
C++0x standard help you eliminate 64-bit errors » ( http:/lwww.viva64.comlen/b/0060 /). 
L’exemple std: : pai r<std : : string, i n t >/s td : : pa i r<const std:: string, int> de ce 
même conseil est tiré de la présentation « STL1 1 : Magic && Secrets » de Stephan T. Lava- 
vej sur G oing Native 2012 ( http://channel9.msdn.com/Events/GoingNative/GoingNative - 
201 2/STLl 1 -M agic-Secrets). Le conseil 6 se fonde sur l’article publié le 12 août 2013 par 
Herb Sutter, « GotW #94 Solution: AAA Style ( Almost Always Auto) » (http://herbsutter. 
com/20 1 3/08/ 1 2/gotW'94'Solution-aaa'Style'almost'alwayS'auto/). Le conseil 9 prend ses 
racines dans le billet posté le 27 mai 2012 par Martinho Femandes, « Handling dépendent 
names » ( http://flamingdangerzone.com/cxxl 1/201 2/05/27 /dependentmames-bliss . html). 
L’exemple du conseil 12 illustrant la surcharge sur les qualificatifs de référence repose sur 
la réponse de Casey à la question « What’s a use case for overloading member functions 
on référencé qualifiera? » (http://stackoverflow.com/questions/21052377 /whatS'a'Use<ase' 
for'overloading'inember'functions'on'reference-qualifiers) posée sur Stack Overflow le 
14 janvier 2014- Au conseil 15, notre description de la prise en charge des fonctions 
constexpr comprend des informations fournies par Rein Halbersma. Le conseil 16 
emprunte énonnément à la présentation « You don’t know const and mutable » de 
Herb Sutter sur C++ and Beyond 2012. Le conseil 18, faire en sorte que les fonctions 
fabriques retournent des std : : uni que_ptr, provient de l’article publié le 30 mai 2013 par 
Herb Sutter, « GotW# 90 Solution: Factories » ( http://herbsutter.com/2013/05/30/gotw - 
90'solution'factories/). Au conseil 20, la fonction fastLoadWidget a été suggérée par 
la présentation « My Favorite C++ 10-Liner » de Herb Sutter sur Going Native 2013 
(http://channel9. msdn.com/Events/GoingNative/ 20 13/My-Favorite-Cpp-lO'Liner). Nos 
explications, au conseil 22, sur std: :unique_ptr et les types incomplets se fondent 
sur l’article publié le 27 novembre 2011 par Herb Sutter, « GotW #100: Compilation 
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Firewalls » ( http://herbsutter.com/gotuil_100 /), ainsi que sur la réponse du 22 mai 201 1 
de Howard Hinnant à la question « Is std::unique_ptr<T> required to know the full 
définition of T? » posée sur Stack Overflow ( http://stackoverflow.com/questions/6012157/ 
iS'Stdunique-ptn-required'to-knoW'the-full'definition'of't). L’exemple d’addition de Matrix 
donné au conseil 25 provient des publications de David Abrahams. Le commentaire 
rédigé le 8 décembre 2012 par JoeArgonne à propos du billet du 30 novembre 2012, 
« Another alternative to lambda move capture » ( http://jrb-programming.blogspot.com/ 
2012/1 l/another'altemative'to'lambda'move.html), est à l’origine de l’approche fondée sur 
std : : bi nd pour la simulation de la capture généralisée de C++ 1 1 décrite au conseil 32. 
Les explications du conseil 37 sur le problème du detach implicite dans le destructeur 
de std : : thread sont tirées de l’article du 4 décembre 2008 rédigé par Hans-J. Boehm, 
« N2802: A plea to reconsider detach-on-destruction for thread objects » (http://www. 
operi'Std.org/jtc 1 /sc22/wg2 1 /docs/papers/2008/n2802 .html). Le conseil 41 a été motivé à 
l’origine par les interrogations de David Abrahams dans son billet du 1 5 août 2009, « Want 
speed?Passby value. » (http://web.archive.org/web/20140l 1 322 1447 Ihttp: /cpp'inext .com/ 
archive/ 2009 108/want'Speed'pasS'by 'Value/). L’idée que les types réservés au déplacement 
méritent un traitement particulier revient à Matthew Fioravante, tandis que l’analyse de 
la copie par affectation découle des commentaires de Howard Hinnant. Au conseil 42, 
Stephan T. Lavavej et Howard Hinnant nous ont aidés à comprendre les différences de 
performances entre les fonctions de placement et d’insertion, et Michael Winterberg a 
attiré notre attention sur les fuites de ressources potentielles liées au placement. Michael 
met ses informations au crédit de la présentation de Sean Parent, « C++ Seasoning », sur 
Going Native 2013, http://charm.el9 .msdn.com/EventslGoingNative/20 1 3/Cpp'Seasoning). 
Michael a également souligné l’utilisation de l’initialisation directe par les fonctions de 
placement, et celle de l’initialisation par copie par les fonctions d’insertion. 

Le travail de relecture d’un ouvrage technique demande beaucoup d’implication, 
de temps et de critique. Nous sommes reconnaissants envers toutes les personnes qui 
ont accepté d’y participer. Les brouillons complets ou partiels de Effective Modem C++ 
ont officiellement été relus par Cassio Neri, Nate Kohl, Gerhard Kreuzer, Leor Zolman, 
Bart Vandewoestyne, Stephan T. Lavavej, Nevin « :-) » Liber, Rachel Cheng, Rob 
Stewart, Bob Steagall, Damien Watkins, Bradley E. Needham, Rainer Grimm, Fredrik 
Winkler, Jonathan Wakely, Herb Sutter, Andrei Alexandrescu, Eric Niebler, Thomas 
Becker, Roger Orr, Anthony Williams, Michael Winterberg, Benjamin Huchley, 
Tom Kirby-Green, Alexey A Nikitin, William Dealtry, Hubert Matthews et Tomasz 
Kaminski. Nous avons également eu le retour de plusieurs lecteurs au travers de 
O’Reilly’s Early Release EBooks et Safari Books Online ’s Rough Cuts, de commentaires 
sur notre blog The View from Aristeia ( http://scottmeyers.blogspot.com/ ), et de courriers 
électroniques. Nous remercions tous ces contributeurs pour leur aide, dont cet ouvrage 
a largement profité. Nous sommes particulièrement redevables à Stephan T. Lavavej et 
Rob Stewart, dont les remarques extraordinairement détaillées et complètes laissent à 
penser qu’ils ont passé plus de temps sur cet ouvrage que nous-mêmes. Merci également 
à Leor Zolman, qui, outre sa relecture du manuscrit, a revérifié tous les exemples de 
code. 

Gerhard Kreuzer, Emyr Williams et Bradley E. Needham se sont chargés de la 
révision des versions électroniques de ce livre. 
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Notre choix de limiter la longueur des lignes de code se fonde sur les informations 
données par Michael Maher. 

Grâce à Ashley Morgan Williams, nos dîners au Lake Oswego Pizzicato ont été 
particulièrement divertissants. 

Plus de 20 ans après ma première expérience d’auteur, ma femme Nancy L. Urbano 
a encore une fois toléré les nombreux mois de conversations distraites, qu’elle 
a accompagnés d’un cocktail de résignation, d’exaspération et de débordements 
opportuns de compréhension et de soutien. 
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Si vous êtes un programmeur C++ expérimenté et si vous nous ressemblez, vous avez 
probablement abordé C++ 11 en pensant : « Oui, oui, j’ai compris. C’est du C++, 
juste amélioré. » Mais, en progressant dans votre apprentissage, vous avez dû être 
surpris par l’étendue des changements. Les déclarations auto, les boucles for basées 
sur une plage, les expressions lambda et les références rvalue ont changé la face de 
C++, sans parler des nouvelles fonctionnalités de concurrence. Ajoutons à cela les 
changements idiomatiques. 0 et typedef sont partis, bienvenue à nul 1 pt r et aux 
déclarations d’alias. Les énumérations peuvent à présent être délimitées. Les pointeurs 
intelligents doivent désormais être préférés aux pointeurs intégrés. Le déplacement 
des objets est normalement plus efficace que leur copie. 

Nous avons beaucoup à découvrir sur C++ 1 1 , et plus encore sur C++ 14. 

Mais le plus important est que nous ayons beaucoup à apprendre sur l’utilisation 
efficace de ces nouvelles possibilités. Si vous recherchez des informations de base sur 
les fonctionnalités du C++ « moderne », les ressources abondent. En revanche, si 
vous cherchez à comprendre comment les employer pour créer un logiciel approprié, 
performant, facile à maintenir et portable, les difficultés commencent. C’est là où cet 
ouvrage peut vous être utile. Il est consacré non pas à la description des fonctionnalités 
de C+ + 1 1 et de C++ 14, mais à leur mise en application efficace. 

Les informations données dans cet ouvrage prennent la forme de recommandations 
réparties en conseils. Voulez-vous comprendre les différentes formes de déduction de 
type ? Souhaitez-vous savoir quand (ne pas) utiliser les déclarations auto 1 Aimeriez- 
vous découvrir pourquoi les fonctions membres const doivent être sûres vis-à-vis des 
threads, comment implémenter l’idiome Pimpl avec std : : uni que_ptr, pourquoi éviter 
le mode de capture par défaut dans les expressions lambda, ou les différences entre 
std : : atomi c et vol ati 1 e ? Toutes les réponses se trouvent ici. Elles sont indépendantes 
de la plate-forme et conformes à la norme. Cet ouvrage présente un C++ portable. 

Les conseils font des recommandations, sans définir des règles, car il existe 
toujours des exceptions. Le point le plus important de chaque conseil est non pas la 
recommandation qu’il donne, mais les raisons qui l’étayent. Après les avoir étudiées, 
vous serez en mesure de déterminer si le cas particulier d’un projet justifie qu’une 
recommandation ne soit pas suivie. Le véritable objectif de ce livre n’est pas de préciser 
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ce que vous devez faire ou ne pas faire, mais de vous apporter une compréhension plus 
profonde du fonctionnement de C+ + 1 1 et de C+ + 14. 


Terminologie et conventions 

Afin d’être certains que nous nous comprenions, il est important que nous soyons 
d’accord sur la terminologie, ne serait-ce que sur « C++ ». Il existe quatre versions 
officielles de C++, dont le nom fait référence à l’année d’adoption de la norme 
ISO correspondante : C++98, C++03, C++1 1 et C ++14- Puisque C++98 et C++03 
diffèrent uniquement sur des détails techniques, nous les regroupons dans cet ouvrage 
sous le nom C++98. Lorsque nous mentionnons C+ + 1 1, il s’agit à la fois de C+ + 1 1 et 
de C+ + 14, car C+ + 14 et un sur-ensemble de C++1 1. Nous précisons C+ + 14 lorsque 
les explications concernent uniquement cette version. Quant à C+ + , cela signifie que 
le contenu est suffisamment général pour correspondre à toutes les versions du langage 
(tableau 1). 


Tableau 1 — 

Terminologie des versions de C++. 

Terme employé 

Versions du langage concernées 

C++ 

Toutes 

C++98 

C++98 et C++03 

C++11 

C++1 1 et C++1 4 

C++ 14 

C++ 14 


Par exemple, nous pouvons écrire que C++ met l’accent sur l’efficacité (vrai 
pour toutes les versions), que C++98 ne prend pas en charge la concurrence (vrai 
uniquement pour C++98 et C++03), que C++11 prend en charge les expressions 
lambda (vrai pour C+ + 1 1 et C+ + 14) et que C+ + 14 offre la déduction généralisée du 
type de retour d’une fonction (vrai uniquement pour C+ + 14). 

La fonctionnalité C++1 1 la plus endémique est probablement la sémantique de 
déplacement, qui se fonde sur la distinction des expressions qui sont des rvalues 
et celles qui sont des Ivalues. En effet, les rvalues signalent des objets éligibles aux 
opérations de déplacement, contrairement aux Ivalues qui, en général, ne le sont pas. 
Conceptuellement (mais pas toujours en pratique), les rvalues correspondent à des 
objets temporaires retournés par des fonctions, tandis que les Ivalues correspondent 
à des objets auxquels nous pouvons faire référence, que ce soit par leur nom ou en 
suivant un pointeur ou une référence lvalue. 

Pour savoir si une expression est une lvalue, une méthode généraliste consiste à 
se demander s’il est possible d’en prendre l’adresse. Dans l’affirmative, il s’agit géné- 
ralement d’une lvalue. Sinon, il s’agit habituellement d’une rvalue. Cette approche 
nous aide également à nous rappeler que le type d’une expression n’est pas lié au fait 
qu’elle soit une lvalue ou une rvalue. Autrement dit, étant donné le type T, nous 
pouvons avoir aussi bien des Ivalues que des rvalues de type T. Il est important de ne 
pas oublier ce point lorsque nous manipulons un paramètre de type référence rvalue 
car le paramètre lui-même est une lvalue : 
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class Widget { 

publ ic: 

Widget(Widget&& rhs); II rhs est une lvalue, même si son type 

// est une référence rvalue. 

I; 

Dans cet exemple, nous pouvons parfaitement prendre l’adresse de rhs dans le 
constructeur de déplacement de Widget. Par conséquent, rhs est une lvalue même si 
son type est une référence rvalue. (Avec un raisonnement similaire, tous les paramètres 
sont des lvalues.) 

Cet extrait de code illustre plusieurs conventions que nous allons suivre : 

• La classe se nomme Wi dget. Nous utilisons Wi dget dès que nous voulons faire 
référence à un type quelconque défini par l’utilisateur. À moins que nous ne 
voulions montrer des détails spécifiques de la classe, nous employons Widget 
sans la déclarer. 

• Le paramètre se nomme rhs (right-hand side, partie du côté droit). Ce nom a 
notre préférence pour les opérations de déplacement (constructeur de déplacement 
et opérateur d’affectation par déplacement) et pour les opérations de copie 
(constructeur de copie et opérateur d’affectation par copie). Nous l’employons 
également pour les paramètres placés à droite des opérateurs binaires : 

Matrix operator+(const Matrix& lhs, const Matrix& rhs); 

Vous ne serez pas surpris d’apprendre que lhs (left-hand side ) correspond à la 
partie du côté gauche. 

• Nous utilisons une mise en forme spéciale pour les parties du code ou des 
commentaires qui exigent votre attention. Dans le constructeur de déplacement 
de Widget, nous avons mis en exergue la déclaration de rhs et la partie du 
commentaire qui révèle que rhs est une lvalue. Le code surligné n’est ni bon ni 
mauvais, il mérite simplement une attention particulière. 

• Nous utilisons « ... » pour indiquer que d’autres lignes de code se trouvent à 
cet emplacement. Il ne faut pas confondre ces points de suspension étroits avec 
les points de suspension larges (« ... ») utilisés dans le code source pour les 
templates variadiques de C++ 1 1 . Malgré les apparences, il n’y a pas de confusion 
possible. Par exemple : 

I templ ate<typename. . . Ts> 

void processVal siconst Ts&... params) 


// Représente d’autres lignes 
// de code. 

La déclaration de processVal s montre que nous utilisons typename pour déclarer 
des paramètres de type dans les templates, mais il s’agit d’une préférence 


// Points de suspension 
// dans du code source 
// C++. 
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personnelle. Le mot clé class convient également. Lorsque nous montrons 
du code qui provient de la norme C++, nous déclarons les paramètres de type 
avec class car c’est le mot clé qu’elle utilise. 

Lorsque l’initialisation d’un objet se fait à partir d’un autre objet du même type, le 
nouvel objet est une copie de l’objet d’initialisation, même si la copie a été créée par le 
constructeur de déplacement. Malheureusement, la terminologie de C++ ne permet 
pas de distinguer un objet qui correspond à une copie construite par copie et un objet 
qui est une copie construite par déplacement : 


void someFunc(Widget w); 

II 


II 

Widget wid; 

II 

someFunc(wid) ; 

II 


II 


II 

someFunc (std: :move(wid) ) ; 

II 


II 


II 


Le paramètre w de someFunc 
est passé par valeur. 

wid est un Widget. 

Dans cet appel à someFunc, 
w est une copie de wid créée via 
une construction par copie. 

Dans cet appel à someFunc, 
w est une copie de wid créée via 
une construction par déplacement. 


Les copies de rvalues sont généralement construites par déplacement, tandis que les 
copies de lvalues sont habituellement construites par copie. En conséquence, si nous 
savons uniquement qu’un objet est une copie d’un autre objet, il nous est impossible de 
connaître le coût de construction de cette copie. Par exemple, dans le code précédent, 
il est impossible de déterminer le coût de la création du paramètre w sans savoir si une 
rvalue ou une lvalue a été passée à someFunc. (Nous devons également connaître le 
coût du déplacement et de la copie des Widget.) 

Dans un appel de fonction, les expressions passées au point d’appel constituent 
les arguments de la fonction. Ils servent à initialiser les paramètres de la fonction. 
Dans le premier appel à la fonction someFunc précédente, l’argument est wid. Dans 
le second appel, il s’agit de std: :move(wid). Dans ces deux appels, le paramètre est 
w. Il est important de faire la différence entre les arguments et les paramètres, car les 
paramètres sont des lvalues, alors que les arguments qui servent à leur initialisation 
peuvent être des rvalues ou des lvalues. Cela concerne en particulier le processus de 
transmission parfaite, au cours duquel un argument passé à une fonction est transmis 
à une seconde fonction en conservant le statut de rvalue ou lvalue de l’argument 
d’origine. (La transmission parfaite fait l’objet du conseil 30.) 

Les fonctions bien conçues sont sûres vis-à-vis des exceptions. Autrement dit, 
elles offrent au moins une garantie de sécurité basique vis-à-vis des exceptions (la 
garantie minimale ). Elles garantissent au code appelant que, même en cas d’exception, 
les invariants du programme sont conservés (aucune structure de données n’est 
corrompue) et aucune ressource n’est perdue. Les fonctions qui offrent une garantie de 
sécurité élevée vis-à-vis des exceptions (la garantie forte) garantissent au code appelant 
que, en cas d’exception, le programme reste dans l’état qu’il avait avant l’appel. 



Dunod - Toute reproduction non autorisée est un délit. 


Introduction 



Lorsque nous faisons référence à un objet fonction, nous parlons en général d’un 
objet dont le type prend en charge une fonction membre opéra tord ). Autrement dit, 
il s’agit d’un objet qui se comporte comme une fonction. Nous employons parfois 
ce terme de façon plus générale pour désigner tout ce qui peut être invoqué à 
l’aide de la syntaxe d’un appel de fonction non-membre (c’est-à-dire « nomDeFonc- 
ti on( arguments ) »). Cette définition plus large couvre non seulement les objets qui 
prennent en charge operatorO, mais également les fonctions et les pointeurs de 
fonctions que l’on trouve en C. (La définition restrictive vient de C++98, la plus 
souple, de C+ + 11.) En ajoutant les pointeurs de fonctions membres, nous arrivons à 
une généralisation encore plus importante : les objets invocables. Les distinctions fines 
peuvent en général être ignorées. Il suffit simplement de voir les objets fonctions et les 
objets invocables comme des éléments de C++ qui peuvent être invoqués au travers 
d’une certaine syntaxe d’appel de fonction. 

Les objets fonctions créés par des expressions lambda sont appelés fermetures. Il 
est rarement nécessaire de distinguer les expressions lambda et les fermetures qu’elles 
génèrent. Nous conservons donc simplement le terme expressions lambda. De manière 
comparable, nous faisons rarement la différence entre les templates de fonctions (c’est- 
à-dire les templates qui génèrent des fonctions) et les fonctions templates (c’est-à-dire 
les fonctions générées à partir de templates de fonctions). Il en va de même pour les 
templates de classes et les classes templates. 

En C++, de nombreux éléments peuvent être déclarés et définis. Une déclaration 
donne le nom et le type sans apporter d’autres détails, comme l’emplacement de la 
mémoire ou la manière d’implémenter les choses : 


T3 

n 


© 


extern Int x; // Déclaration d’un objet. 

class Widget; // Déclaration d’une classe. 

bool func(const Widget& w); // Déclaration d’une fonction. 

enum class Col or ; // Déclaration d’une énumération 

// délimitée (voir le conseil 10). 

Une définitioti précise l’emplacement de la mémoire ou les détails d’implémenta 
tion : 


int x; 

class Widget ( 


bool func(const Widget& w) 

( return w.sizeO < 10; I // Définition d’une fonction, 

enum class Color 

( Vellow, Red, Blue i; // Définition d’une énumération 

// délimitée. 


// Définition d’un objet. 

// Définition d’une classe. 


Copyright © 2016 Dunod. 



Programmer efficacement en C++ 


Une définition est également une déclaration. Par conséquent, à moins qu’il ne 
soit réellement important d’avoir une définition, nous préférons les déclarations. 

La signature d’une fonction correspond à la partie de sa déclaration qui précise les 
types des paramètres et le type de retour. Les noms de la fonction et des paramètres 
ne sont pas compris dans la signature. Dans l’exemple précédent, la signature de f une 
est bool ( const Wi dget&). Les éléments de la déclaration d’une fonction autres que les 
types de ses paramètres et de sa valeur de retour (par exemple les mots clés noexcept 
ou constexpr, le cas échéant) sont exclus, (noexcept et constexpr sont décrits aux 
conseils 14 et 15.) La définition officielle d’une signature est légèrement différente de 
la nôtre (elle omet parfois le type de retour), mais, dans le cadre de cet ouvrage, notre 
définition est plus utile. 

Les nouvelles normes de C++ préservent en général la validité du code écrit 
selon des normes plus anciennes, mais le comité de normalisation déclare parfois 
certaines fonctionnalités obsolètes. Ces fonctionnalités sont placées sur une voie de 
garage et risquent de disparaître des normes futures. Le compilateur informe parfois 
de l’utilisation des fonctionnalités obsolètes, mais il est préférable de les éviter. Elles 
peuvent non seulement conduire à des problèmes de portage ultérieur, mais elles sont 
également souvent inférieures aux fonctionnalités qui les remplacent. Par exemple, 
l’utilisation de std : : auto_ptr est désapprouvée enC++l 1, car std : : unique_ptr assure 
la même fonction, en mieux. 

La norme stipule parfois qu’une opération a un comportement indéfini. Cela signifie 
que son comportement à l’exécution est imprévisible et il va sans dire qu’il vaut mieux 
rester loin d’une telle incertitude. Parmi les exemples de comportement indéfini 
mentionnons l’utilisation des crochets (« [] ») avec un indice qui dépasse les limites 
d’un std: :vector, le déréférencement d’un itérateur non initialisé ou l’entrée dans 
une condition de concurrence (c’est-à-dire deux threads ou plus, l’un d’eux étant un 
écrivain, qui accèdent simultanément au même emplacement mémoire). 

Les pointeurs intégrés, comme ceux renvoyés par new, sont appelés pointeurs bruts. 
À l’opposé d’un pointeur brut, nous trouvons le pointeur intelligent. Les pointeurs 
intelligents surchargent normalement les opérateurs de déréférencement d’un pointeur 
(operator-> et operator*), mais le conseil 20 explique que std: :weak_ptr fait 
exception. 
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Signaler des bogues ou suggérer des améliorations 

Nous avons fait de notre mieux pour que les informations données dans cet ouvrage 
soient claires, précises et utiles. Néanmoins, il reste toujours de la place pour des 
améliorations. Si vous trouvez des erreurs de quelque sorte que ce soit (techniques, 
explicatives, grammaticales, typographiques, etc.) ou si vous avez des suggestions pour 
améliorer cet ouvrage, n’hésitez pas à nous contacter 1 par courrier électronique à 
l’adresse emc++@aristeia.com. Les nouvelles impressions nous donnent l’opportunité 
de réviser Programmer efficacement en C++, mais nous ne pouvons pas traiter les 
problèmes dont nous n’avons pas connaissance ! 

Pour consulter la liste des problèmes connus rendez-vous sur la page dédiée 2 
( htt p : // www . aris teia . com/BookErratal emc++'errata .html). 
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1 . En anglais de préférence. 

2. Page de la version originale américaine. 
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En C++98, un seul jeu de règles servait à déduire les types, celui employé pour 
les templates de fonctions. C+ + 11 a ajouté deux règles, l’une pour auto, l’autre 
pour decl type. C+ + 14 a ensuite étendu les contextes d’utilisation de ces deux mots 
clés. Grâce à une généralisation toujours plus importante de l’inférence de type, le 
programmeur n’est plus obligé de préciser les types qui sont évidents ou redondants. 
Le logiciel écrit en C++ devient plus flexible car la modification d’un type en un point 
du code source se propage automatiquement aux autres emplacements. En revanche, 
le code est peut-être plus difficile à analyser car les types déduits par les compilateurs 
risquent de ne pas apparaître aussi clairement que souhaité. 

Sans une parfaite compréhension du fonctionnement de la déduction de type, il 
est pratiquement impossible de programmer efficacement dans un C++ moderne. Les 
contextes d’utilisation de l’inférence de type sont tout simplement trop nombreux : 
dans les appels aux templates de fonctions, dans la plupart des cas où auto apparaît, 
dans les expressions decl type et, depuis C++ 14, dans les énigmatiques constructions 
decltype(auto). 

Dans ce chapitre, le développeur C++ trouvera toutes les informations dont il 
a besoin sur la déduction des types. Nous y expliquons le fonctionnement de la 
déduction de type de template, comment elle est exploitée par auto et comment 
procède decl type. Nous précisons également comment obliger les compilateurs à 
dévoiler les résultats de leurs déductions afin que nous puissions vérifier qu’elles 
correspondent à nos attentes. 
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CONSEIL N° 1 . COMPRENDRE LA DEDUCTION 
DE TYPE DE TEMPLATE 

Lorsque l’on est capable d’utiliser un système complexe sans en comprendre le 
fonctionnement, tout en étant satisfait du résultat, on peut imaginer que ce système 
est bien conçu. Sur ce point, la déduction de type de template de C++ est une réussite 
incontestable. Des millions de programmeurs passent des arguments à des fonctions 
templates, avec des résultats totalement satisfaisants, et, pourtant, la plupart d’entre 
eux auraient bien du mal à donner une description autre que vague de la manière dont 
les types employés par ces fonctions ont été déterminés. 

Si vous faites partie de ces personnes dans le flou, nous avons de bonnes et de 
mauvaises nouvelles. Tout d’abord, sachez que l’inférence de type pour les templates 
constitue le socle de l’une des fonctionnalités les plus intéressantes du C++ moderne : 
auto. Si vous étiez satisfait de la façon dont C++98 déduisait les types, vous ne serez 
pas déçu par la déduction de type auto en C++ 1 1. Cependant, l’application des règles 
dans le contexte de auto semblera parfois moins intuitive que dans le contexte des 
templates. Il est donc indispensable de maîtriser tous les aspects de la déduction de 
type de template sur lesquels se fonde auto. Tel est l’objectif de ce conseil. 

Si vous êtes prêt à accepter un petit bout de pseudocode, voici comment se présente 
un template de fonction : 


| template<typename T> 
void f {ParamType param); 

Et voici comment se présente un appel à cette fonction : 


f (expr); Il Appeler f avec une expression. 

Au cours de la compilation, le compilateur se sert de expr pour déduire le 
type de T et celui de ParamType. Ces types sont souvent différents car ParamType 
est généralement accompagné d’autres mots clés, comme const ou un qualificatif 
de référence. Supposons, par exemple, que le template soit déclaré de la manière 
suivante : 

| template<typename T> 

void f(const T& param); II ParamType correspond à const T&. 

et que nous ayons l’appel suivant : 


int x = 0; 


f (x) ; 


// Appeler f avec un int. 


T est déterminé comme étant de type i nt, mais ParamType est de type const i nt&. 
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Il est normal d’imaginer que le type déduit pour T soit celui de l’argument passé 
à la fonction, autrement dit que T soit le type de expr. C’est le cas dans l’exemple 
précédent : x est un int et T est déterminé comme étant de type int. Mais cela ne 
fonctionne pas toujours ainsi. Le type déduit pour T dépend non seulement du type de 
expr , mais également de la forme de ParamType. Il existe trois cas : 

• ParamType est un pointeur ou une référence, mais sans être une référence 
universelle. (Les références universelles font l’objet du conseil 24. À ce stade, 
sachez simplement qu'elles existent et sont différentes selon qu’elles sont des 
lvalues ou des rvalues.) 

• ParamType est une référence universelle. 

• ParamType n’est ni un pointeur ni une référence. 

Nous devons donc étudier trois scénarios pour la déduction de type. Chacun 
reprend la forme générale d’un template et de son appel : 

templ ate<typename T> 

void f (ParamType parait); 

f (expr); Il Déduire T et ParamType à partir de expr. 


Cas 1 : ParamType est un pointeur ou une référence non universelle 

Examinons la situation la plus simple, lorsque ParamType est un pointeur ou une 
référence, sans être une référence universelle. Dans ce cas, voici comment fonctionne 
la déduction de type : 

1. Si le type de expr est une référence, ignorer la partie référence. 

2. Effectuer ensuite une correspondance de motif entre le type de expr et Param- 
Type de façon à déterminer T. 

Prenons comme exemple le template suivant : 

I templ ate<typename T> 

void f ( T& param); // param est une référence. 

et ces déclarations de variables : 


int x = 27; // x est un int. 

const int ex = x; // ex est un const int. 

const int& rx = x; // rx est une référence à x de type const int. 

Voici les types déduits pour param et T dans les différents appels : 

f ( x ) ; // T est de type int, param de type int&. 


f (ex) ; 


Il T est de type const int. 
Il param de type const int&. 
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f(rx); Il T est de type const int. 

Il param de type const int&. 

Vous noterez que, dans les deuxième et troisième appels, puisque ex et rx désignent 
des valeurs const, T est déterminé comme étant const int et le type du paramètre 
est donc const i nt&. Ce point est important pour les appels. En effet, lorsqu’un objet 
const est passé à un paramètre de type référence, on suppose que cet objet reste non 
modifiable, c’est-à-dire que le paramètre est une référence à un const. C’est pour cette 
raison que passer un objet const à un template qui prend un paramètre T& est sûr : le 
caractère const de l’objet fait partie du type déduit pour T. 

Dans le troisième exemple, vous remarquerez que, même si rx est de type référence, 
T est déterminé comme n’étant pas une référence. En effet, le fait que rx soit une 
référence est ignoré au cours de la déduction de type. 

Les paramètres de tous ces exemples sont des références lvalue, mais la déduction 
de type opère de la même manière pour les références rvalue. Bien entendu, seules des 
rvalues peuvent être passées en arguments si les paramètres sont des références rvalue, 
mais cette contrainte n’a aucun rapport avec la déduction de type. 

Si nous modifions le type du paramètre de f, en remplaçant T& par const T&, les 
résultats sont légèrement différents, mais sans réelle surprise. Le caractère const de ex 
et de rx est toujours respecté, mais, puisque nous supposons à présent que param est 
une référence à un const, il est inutile que const soit compris dans la déduction du 
type de T : 


templ ate<typename T> 


void f(const T& param) ; 

II 

param 

int x = 27; 

II 

Comme 

const int ex = x; 

II 

Comme 

const i nt& rx = x; 

II 

Comme 

f (x) ; 

II 

T est 

f (ex) ; 

II 

T est 

f (rx) ; 

II 

T est 


est une référence à un const. 

précédemment. 

précédemment. 

précédemment. 

de type int, param de type const int&. 

de type int, param de type const int&. 

de type int, param de type const int&. 


Comme précédemment, le fait que rx soit une référence est ignoré au cours de la 
déduction de type. 

Si param était non plus une référence mais un pointeur, ou un pointeur sur un 
const, le fonctionnement serait quasi identique : 


templ ate<typename T> 

void f(T* param); // param est à présent un pointeur. 


int x = 27; 
const int *px = &x; 


Il Comme précédemment. 

Il px est un pointeur sur x de type const int. 
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f (&x ) ; // T est de type int, param de type int*. 

f(px); // T est de type const int. 

Il param de type const int*. 

Vous êtes probablement en train de bailler car les règles de déduction de type de 
C++ pour les paramètres de type référence et pointeur sont si naturelles que les lire se 
révèle particulièrement ennuyeux. Tout est si évident ! Mais c’est précisément ce que 
nous attendons d’un système de déduction de type. 

Cas 2 : ParamType est une référence universelle 

Le fonctionnement est moins évident lorsque les templates prennent en paramètres 
des références universelles. Ces paramètres sont déclarés comme des références rvalue 
(autrement dit, dans un template de fonction qui prend un paramètre de type T, la 
déclaration de type d’une référence universelle est T&&), mais le comportement est 
différent lorsque des arguments lvalue sont transmis. Tous les détails seront donnés au 
conseil 24, mais en voici une version résumée : 

• Si expr est une lvalue, T et ParamType sont tous deux déterminés comme des 
références lvalue. C’est plutôt inhabituel, à deux points de vue. Premièrement, 
il s’agit du seul cas de déduction de type de template où T est déterminé comme 
une référence. Deuxièmement, même si ParamType est déclaré avec la syntaxe 
associée à une référence rvalue, son type déduit correspond à une référence 
lvalue. 

• Si expr est une rvalue, les règles « normales » (c’est-à-dire le cas 1 ) s’appliquent. 
Par exemple : 

templ ate<typename T> 

void f ( T&& param); // param est à présent une référence universelle. 

int x = 27; // Comme précédemment, 

const int ex = x; // Comme précédemment, 

const i nt& rx = x; // Comme précédemment. 

f (x) ; // x est une lvalue, T est donc de type int& 

Il et param également de type int&. 

f ( ex ) ; Il ex est une lvalue, T est donc de type const int& 

Il et param également de type const int&. 

f(rx); Il rx est une lvalue, T est donc de type const int& 

Il et param également de type const int&. 

f ( 27 ) ; Il 27 est une rvalue, T est donc de type int 

Il et param donc de type int&&. 

Le conseil 24 explique précisément le fonctionnement de ces exemples. Il faut 
retenir ici que les règles de déduction de type pour les paramètres qui sont des 
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références universelles diffèrent de celles des paramètres qui sont des références 
Ivalue ou rvalue. En particulier, avec des références universelles, la déduction de 
type distingue les arguments Ivalue et les arguments rvalue. Cela ne se produit jamais 
pour les références non universelles. 


Cas 3 : ParamType n'est ni un pointeur ni une référence 

Lorsque ParamType n’est ni un pointeur ni une référence, nous sommes dans le cas 
d’un passage par valeur : 

I templateCtypename T> 

void f ( T param); // param est passé par valeur. 

Cela signifie que param sera une copie de l’argument transmis, c’est-à-dire un objet 
totalement nouveau. Cet état de fait dicte les règles de déduction du type de T à partir 
de expr : 

1. Comme précédemment, si le type de expr est une référence, ignorer la partie 
référence. 

2. Si, après avoir ignoré la partie référence de expr, expr est const, ignorer 
également cette caractéristique. Faire de même s’il est volatile. (Les objets 
volatile sont rares et servent généralement à l’implémentation de pilotes de 
périphériques. Pour de plus amples informations, consultez le conseil 40.) 

Poursuivons notre exemple : 


int x = 27; 
const int ex = x; 
const int& rx = x; 

f (x) ; 

f (ex) ; 

f ( rx) ; 


// Comme précédemment. 

// Comme précédemment. 

// Comme précédemment. 

// T et param sont tous deux des int. 

// T et param sont à nouveau des int. 

// T et param sont toujours des int. 


Vous remarquerez que même si ex et rx représentent des valeurs const, param n’est 
pas const. C’est parfaitement normal car param est un objet totalement indépendant 
de ex et de rx — une copie de ex ou de rx. Le fait que ex et rx ne puissent pas être 
modifiés ne donne aucune indication sur les possibilités de modification de param. 
C’est pourquoi le caractère const (ou vol a t i 1 e) de expr est ignoré au moment de la 
déduction du type pour param ; ce n’est pas parce que expr ne peut pas être modifié 
que sa copie ne peut pas l’être. 

Il est important de comprendre que const (et volatile) est ignoré uniquement 
pour les paramètres passés par valeur. Nous l’avons vu, pour les paramètres qui sont des 
références ou des pointeurs vers des const, cette caractéristique de expr est préservée 
au cours de la déduction de type. Toutefois, examinons le cas où expr est un pointeur 
const sur un objet const et où expr est passé par valeur à param : 
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templ ateCtypename T> 

void f (T param); Il param est encore passé par valeur. 


const char* const ptr = 
" Fun with pointers 


Il ptr est un pointeur const sur un objet 
Il const. 


f(ptr) ; 


Il Passer un argument de type 
Il const char * const. 


Dans cet exemple, le mot clé const placé à droite de l’astérisque déclare que ptr 
est constant : il est impossible de faire pointer ptr ailleurs et il ne peut pas être fixé 
à nul 1 . (Le mot clé const à gauche de l’astérisque indique que l’élément pointé par 
ptr - la chaîne de caractères - est constant et qu’il ne peut donc pas être modifié.) 
Lorsque ptr est passé à f, les bits qui composent le pointeur sont copiés dans pa ram. Le 
pointeur lui-même (ptr) est donc passé par valeur. Conformément à la règle de déduction 
de type pour les paramètres par valeur, le caractère const de ptr est ignoré et le type 
déduit pour param sera const char*, c’est-à-dire un pointeur modifiable sur une chaîne 
de caractères constante. Le caractère const de l’élément sur lequel ptr pointe est 
conservé pendant la déduction de type, mais celui de ptr lui-même est ignoré lors de 
sa copie pour créer le nouveau pointeur, param. 


Tableaux en arguments 

Voilà qui couvre essentiellement tous les cas généraux de la déduction de type 
de template, mais vous devez avoir connaissance d’un cas particulier. Il s’agit des 
types tableaux, qui sont différents des types pointeurs même s’ils semblent parfois 
interchangeables. En effet, dans de nombreux contextes, un tableau se dégrade ( decay ) 
en un pointeur sur son premier élément. C’est grâce à cette dégradation que le code 
suivant peut être compilé : 


-o 

n 
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const char name[] = "J. P. Briggs"; Il name est de type const char [13] . 

const char * ptrToName = name; Il Dégradation du tableau en 

Il pointeur. 

Le pointeur ptrToName de type const char* est initialisé avec name, qui est de 
type const char[13]. Ces deux types, const char* et const cha r [13], ne sont pas 
identiques, mais, en raison de la règle de dégradation d’un tableau en pointeur, le code 
est compilable. 

Mais que se passe-t-il lorsqu’un tableau est transmis à un template qui attend un 
paramètre passé par valeur ? 


templ atettypename T> 

void f ( T param); // Template avec un paramètre passé par valeur, 

f (name) ; 


// Quels types sont déduits pour T et param? 
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Observons tout d’abord qu’il n’y a aucun paramètre de fonction qui soit un tableau. 
La syntaxe est parfaitement valide : 

void myFuncCint param[]); 

mais la déclaration de tableau est traitée comme une déclaration de pointeur. 
Autrement dit, myFunc pourrait également être déclarée de la manière suivante : 

void myFuncdnt* param); // Même fonction que précédemment. 

Cette équivalence entre les paramètres de type tableau et de type pointeur prend 
ses racines dans le langage C ayant servi de base à C++ et nourrit l’illusion qu’il n’y a 
aucune différence entre les types tableau et pointeur. 

Puisque la déclaration d’un paramètre de type tableau est traitée comme s’il 
s’agissait d’un paramètre de type pointeur, le type d’un tableau passé par valeur à 
une fonction template est déterminé comme étant de type pointeur. Cela signifie que, 
dans l’appel au template f, le type déduit pour T est const char* : 

I f(name); // name est un tableau, mais le type déduit 

// pour T est const char*. 

Attention toutefois, car si les fonctions ne peuvent pas déclarer des paramètres qui 
soient réellement des tableaux, elles peuvent en déclarer qui sont des références à des 
tableaux ! Modifions le template f de sorte qu’il prenne son argument par référence : 

templ ate<typename T> 

void f(T& param); // Template avec un paramètre passé par 

// référence. 

et passons-lui un tableau : 

f(name); // Passer un tableau à f. 

Dans ce cas, le type déduit pour T est le véritable type du tableau ! Il comprend la 
taille du tableau (dans cet exemple, le type déduit pour T est donc const char [13]) 
et le type du paramètre de f (une référence à ce tableau) est const char (&) [13]. La 
syntaxe a effectivement un côté malsain, mais la connaître vous permettra d’obtenir 
l’estime des quelques personnes qui y tiennent. 

Grâce à cette possibilité de déclarer des références à des tableaux, nous pouvons 
créer un template qui déduit le nombre d’éléments contenus dans un tableau : 

// Renvoyer la taille d’un tableau sous forme d’une constante 
// définie à la compilation. (Le paramètre de type tableau n’a pas de 
// nom, car seul le nombre d’éléments qu’il contient nous intéresse.) 
templ ate<typename T, std::size_t N> // Voir ci-après 

constexpr std::size_t arraySize(T ( & ) [ N ] ) noexcept // pour constexpr 
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return N; 


Il et noexcept. 


Le conseil 15 l’expliquera, en déclarant cette fonction constexpr nous pouvons 
disposer de sa valeur de retour au moment de la compilation. Il est ainsi possible de 
déclarer, par exemple, un tableau avec le même nombre d’éléments qu’un deuxième 
tableau dont la taille est calculée à partir d’un initialiseur à accolades : 

int keyVal s [ ] = { 1, 3, 7, 9, 11, 22, 35 I; // keyVals contient 

// 7 éléments. 

int mappedVal s[arraySize( keyVal s ) ] ; // Et donc mappedVals 

// également. 

Bien entendu, en tant que développeur C++ moderne, vous préférerez utiliser 
std : : array pour construire un tableau : 

| std::array<int, arraySize(keyVals)> mappedVals; // La taille de 

// mappedVals est 7. 

Quant à la déclaration noexcept de arraySize, il s’agit d’aider le compilateur à 
produire un meilleur code. Vous trouverez les informations détaillées au conseil 14. 


Fonctions en arguments 

En C++, la dégradation en pointeurs ne concerne pas uniquement les tableaux. 
Les types fonctions peuvent se dégrader en pointeurs de fonctions et toutes nos 
explications sur la déduction de type pour les tableaux s’appliquent également à celle 
des fonctions et à leur dégradation en pointeurs de fonctions. Par conséquent ; 


"O 
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void someFuncdnt, double); 


Il someFunc est une fonction, 
Il de type void(int, double). 


templ atektypename T> 

void f 1 ( T param); Il Dans fl, param est passé par valeur, 

templ ate<typename T> 

void f 2 ( T& param); Il Dans f 2 , param est passé par référence. 


fl(someFunc) ; 


Il Type déduit pour param : pointeur de 
// fonction, de type void (*)(int, double). 


f2( someFunc) ; 


// Type déduit pour param : référence de 
// fonction, de type void (&)(int, double). 


Dans la pratique, cela fait rarement une différence. Mais si vous devez connaître 
la dégradation des tableaux en pointeurs, il n’est pas inutile de connaître également 
celle des fonctions en pointeurs. 
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Et voilà pour les règles de déduction de type de template associées à auto. Nous 
avons mentionné leur relative simplicité au début du conseil et c’est le cas pour la 
plupart. Le traitement particulier accordé aux lvalues lors de la déduction des types 
pour des références universelles rend cependant les choses un peu plus confuses, tout 
comme les règles de dégradation des tableaux et des fonctions en pointeurs. Parfois, 
vous voudrez simplement demander à votre compilateur : « Dis-moi quel type tu as 
déterminé ! » Lorsque cela se produira, consultez le conseil 4 car il traite justement de 
cette question. 


À retenir 

• Lors de la déduction de type de template, les arguments qui sont des références 
sont traités comme s'ils n'étaient pas des références. Autrement dit, leur statut 
de référence est ignoré. 

• Lors de la déduction de type pour des paramètres qui sont des références 
universelles, les arguments Ivalue font l'objet d'un traitement spécifique. 

• Lors de la déduction de type pour des paramètres passés par valeur, les 
arguments const et/ou volatile sont traités comme s'ils n'étaient pas const ou 
volatile. 

• Lors de la déduction de type de template, les arguments qui sont des noms de 
tableaux ou de fonctions se dégradent en pointeurs, à moins qu'ils ne servent à 
initialiser des références. 


CONSEIL N° 2. COMPRENDRE LA DEDUCTION 
DE TYPE AUTO 

Si vous avez lu le conseil 1 sur la déduction de type de template, vous savez déjà 
pratiquement tout ce que vous devez savoir sur la déduction de type auto. En effet, 
à une seule étrange exception près, elle est identique à celle de template. Comment 
peut-il en être ainsi ? La déduction de type de template implique des templates, des 
fonctions et des paramètres, alors que tous ces éléments sont absents avec auto. 

C’est vrai, mais cela n’a pas d’importance. Il existe une correspondance directe 
entre la déduction de type de template et celle pour auto. Elles sont liées par une 
transformation algorithmique. 

Au conseil 1, nous avons expliqué la déduction de type de template en utilisant le 
template de fonction général suivant : 

I templ ate<typename T> 
void f ( ParamType param); 

et cette forme d’appel : 


f ( expr ) ; 


Il Appeler f avec une expression. 
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Dans un appel à f , le compilateur se sert de expr pour déduire le type de T et de 

P a ramType. 

Lorsqu’une variable est déclarée avec auto, ce mot clé tient le rôle de T dans 
le template, et le spécificateur de type de la variable, celui de Pa ramType. Ce 
fonctionnement sera plus simple à comprendre à partir d’exemples : 

auto x = 27 ; 

Dans ce cas, le spécificateur de type pour x est simplement auto. Avec la déclaration 
suivante : 

const auto ex = x; 

le spécificateur de type est const auto. Et là : 
const auto& rx = x; 

le spécificateur de type est const auto&. Pour déduire les types de x, ex et rx dans ces 
exemples, le compilateur fait comme s’il existait un template pour chaque déclaration 
ainsi qu’un appel à ce template avec l’expression d’initialisation appropriée : 
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templ ate<typename T> 


II 

void func_for_x(T param); 


II 

func_for_x(27) ; 


II 



II 

templ ate<typename T> 


II 

void func_for_cx( const T 

param) ; 

II 

func_for_cx(x) ; 


II 



II 

templ ate<typename T> 


II 

void func_for_rx( const T& 

param) ; 

II 

func_for_rx(x) ; 


II 



II 


Template conceptuel pour déduire 
le type de x. 

Appel conceptuel : le type déduit 
pour param est le type de x. 

Template conceptuel pour déduire 
le type de ex. 

Appel conceptuel : le type déduit 
pour param est le type de ex. 

Template conceptuel pour déduire 
le type de rx. 

Appel conceptuel : le type déduit 
pour param est le type de rx. 


Répétons-le, à une seule exception près, que nous verrons plus loin, la déduction 
des types pour auto est identique à celle pour les templates. 

Au conseil 1, nous avons vu que la déduction de type de template considère trois 
cas, selon les caractéristiques de Pa ramType, le spécificateur de type pour param dans 
le template de fonction général. Dans la déclaration d’une variable avec auto, le 
spécificateur de type prend la place de ParamType, et nous avons donc encore trois cas : 

• Cas 1 : le spécificateur de type est un pointeur ou une référence non universelle. 

• Cas 2 : le spécificateur de type est une référence universelle. 
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• Cas 3 : le spécificateur de type n’est ni un pointeur ni une référence. 

Nous avons déjà présenté des exemples pour les cas 1 et 3 : 

auto x = 27; // Cas 3 (x n’est ni un pointeur ni une référence), 

const auto ex = x; // Cas 3 (idem pour ex). 

const auto& rx = x; // Cas 1 (rx est une référence non universelle). 

Le cas 2 ne vous surprendra pas : 

auto&& urefl = x; // x est un int et une lvalue, 

// urefl est donc de type int&. 

auto&& uref2 = ex; // ex est un const int et une lvalue, 

// uref2 est donc de type const int&. 

auto&& uref3 = 27; // 27 est un int et une rvalue, 

// uref3 est donc de type int&&. 

À la fin du conseil 1, nous avons expliqué la dégradation des tableaux et des 
fonctions en pointeurs lorsque les spécificateurs de types ne sont pas des références. 
Cela se produit également lors de la déduction de type auto : 

I const char name[] = Il name est de type is const cha r [ 13] . 

"R. N. Briggs"; 

auto arrl = name; Il arrl est de type const char*. 

auto& arr2 = name; Il arr2 est de type const char (<S)[13]. 

void someFunc( int, double); Il someFunc est une fonction. 

Il de type void(int, double). 

auto funcl = someFunc; Il funcl est de type 

Il void (*)(int, double). 

auto& func2 = someFunc; Il func2 est de type 

Il void (ÆHint, double). 

Vous le constatez, la déduction de type auto se passe de la même manière que la 
déduction de type de template. Elles sont au fond les deux faces d’une même pièce. 

Mais voici leur point de divergence. Commençons par observer que, pour déclarer 
un i nt de valeur initiale 27, C++98 offre deux syntaxes : 


int xl = 27; 
int x2 ( 27 ) ; 
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C+ + 1 1, malgré sa prise en charge de l’initialisation uniforme, ajoute les possibilités 
suivantes : 


I int x3 = f 27 }; 
int x4{ 27 }; 

Autrement dit, quatre syntaxes pour un seul et même résultat : un i nt de valeur 27. 

Cependant, comme nous l’expliquerons au conseil 5, la déclaration de variables 
avec auto à la place d’un type figé présente quelques avantages. Il serait donc bon de 
remplacer int par auto dans les déclarations de variables précédentes : 


T3 
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auto xl = 27 ; 
auto x2 ( 27 ) ; 
auto x3 = I 27 ) ; 
auto x4{ 27 ) ; 


Si la compilation de ces déclarations ne pose pas de difficultés, elles n’ont pas la 
même signification que celles d’origine. Les deux premières instructions déclarent bien 
une variable de type i nt qui a la valeur 27. En revanche, les deux dernières déclarent 
une variable de type std : : i ni t i al i zer_l i s t < i nt> qui contient un seul élément ayant 
la valeur 27 ! 


auto 

xl 

= 27; 

II 

De type 

int. 

de va 

auto 

x2(27) ; 

II 

Idem. 



auto 

x3 

= 1 27 1: 

II 

De type 

std: 

: i ni 1 7 




II 

de valeur ( 

27 ). 

auto 

x4( 

27 ); 

II 

Idem. 




Ce résultat vient d’une règle particulière de la déduction de type pour auto. Lorsque 
l’initialiseur d’une variable déclarée avec auto est placé entre accolades, le type déduit 
est std : : ini tial i zer_l i st 1 . S’il n’est pas possible de déduire ce type, par exemple en 
raison de valeurs entre accolades de types différents, le code est rejeté : 


I auto x5 = I 1, 2, 3.0 ); // Erreur ! Impossible de déduire T pour 

// std: : initial izer_list<T>. 

Comme l’explique le commentaire, la déduction de type échoue dans ce cas, mais 
il est important de comprendre qu’en réalité deux sortes de déduction de type ont 


1. En novembre 2014, le Comité de normalisation de C++ a adopté la proposition N3922, qui 
supprime la règle spécifique de déduction de type pour auto et les initialiseurs entre accolades 

avec une syntaxe d’initialisation directe, c’est-à-dire sans signe « = » avant les accolades (voir le 
conseil 42). Avec la proposition N3922 (qui ne fait pas partie de C+ + 1 1 et de C+ + 14, mais qui a 
été mise en œuvre par certains compilateurs), x4 dans les exemples précédents n’est plus de type 
std: :initializer_list<int> mais int. 
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lieu. La première découle de l’utilisation de auto : le type de x5 doit être déduit. 
Puisque l’initialiseur de x5 est placé entre des accolades, le type déduit pour x5 doit 
être std : : i ni ti al i zer_l i st. Mais std : : i ni ti al i zer_l i st est un template. Pour un 
type T, les instanciations sont std : : i ni ti al i zer_l i st<T>, et cela signifie que le type 
de T doit aussi être déduit. Cette déduction est du domaine de la seconde sorte : la 
déduction de type de template. Dans cet exemple, cette déduction échoue car les 
valeurs d’initialisation placées entre les accolades ne sont pas d’un seul et même type. 

C’est uniquement dans le traitement des initialiseurs entre accolades que la 
déduction de type auto et la déduction de type de template diffèrent. Lorsqu’une 
variable déclarée avec auto est initialisée à l’aide de valeurs entre accolades, le 
type déduit est une instanciation de std : : i ni ti al i zer_l i st. Cependant, si le même 
initialiseur est passé au template correspondant, la déduction de type échoue et le 
code est rejeté : 


auto x = { 11, 23, 9 }; // x est de type 

// std: :initializer_list<int>. 


templ ate<typename T> // Template avec une déclaration de paramètre 
void f ( T param); // équivalente à la déclaration de x. 


f({ 11, 23, 9 }); 


// Erreur ! Impossible de déduire le type 
// pour T. 


Toutefois, si nous indiquons dans le template que param est un 
std : : i ni ti al izer_l i st<T> pour un T inconnu, la déduction de type de template 
pourra déterminer le type de T : 


templ ate<typename T> 

void f ( std : :initializer_list<T> initList); 

f({ 11, 23, 9 }): // Le type déduit pour T est int, et le type 

// de initList est std: : 1 n i t i a 1 izer_l i s t < i n t> . 

Par conséquent, la seule véritable différence entre les déductions de type auto et 
celle de template vient du fait que, dans le cas de auto et contrairement aux templates, 
un initialiseur entre accolades est supposé représenter un std : : i ni ti al i zer_l i st. 

Vous vous demandez peut-être pourquoi la déduction de type auto emploie une 
règle particulière pour les initialiseurs entre accolades, ce que ne fait pas celle de 
template. Nous nous posons la même question. Hélas, nous n’avons pas pu trouver 
d’explication convaincante. Mais les règles sont les règles, et vous ne devez donc pas 
oublier que si vous déclarez une variable avec auto et l’initialisez avec des valeurs entre 
accolades, le type déduit sera toujours std : : i ni ti al i zer_l i st. Il est particulièrement 
important de garder ce point à l’esprit si vous adoptez l’initialisation uniforme, c’est-à- 
dire placez les valeurs d’initialisation entre accolades. Avec C++ 1 1, l’une des erreurs 
classiques est de déclarer par mégarde une variable std : : i ni ti al i zer_l i st alors 
que l’objectif était une autre déclaration. C’est en raison de ce danger que certains 
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développeurs placent des accolades autour des initialiseurs uniquement lorsqu’elles 
sont indispensables (le conseil 7 explique quand cela est nécessaire). 

L’histoire se termine là pour C++1 1, mais elle continue pour C++ 14. En C++ 14, 
il est possib le d’utiliser auto pour indiquer que le type de retour d’une fonction doit 
être déduit (voir le conseil 3) et les déclarations de paramètre des expressions lambda 
peuvent employer auto. Cependant, dans ces utilisations de auto, la déduction de 
type concernée est non pas celle de auto mais celle de template. Par conséquent, le 
compilateur refusera une fonction qui a un type de retour auto et qui renvoie un 
initialiseur entre accolades : 

auto createlnitListi ) 

I 

return { 1, 2, 3 }; // Erreur ! Impossible de déduire le type 

I // pour I 1, 2, 3 }. 

La situation est identique lorsque la spécification du type d’un paramètre d’une 
expression lambda en C++ 14 utilise auto : 


std: : vector<int> v; 


auto resetV = 

[&v] ( const auto& newValue) { v = newValue; I; // C++14. 


resetVd 1, 2, 3 }); // Erreur ! Impossible de déduire le type 

// pour { 1, 2, 3 I. 


À retenir 

• La déduction de type auto est en général identique à la déduction de type 
de template, mais elle suppose qu'un initialiseur entre accolades représente 
un std : : i ni ti al i zerj ist, ce qui n'est pas le cas de la déduction de type de 
template. 

• L'utilisation de auto dans le type de la valeur de retour d'une fonction ou 
d'un paramètre d'une expression lambda conduit à une déduction de type de 
template, non à la déduction de type auto. 


CONSEIL N° 3. COMPRENDRE DECLTYPE 


© 


decltype est une créature plutôt étrange. Si nous lui donnons un nom ou une 
expression, elle vous indique le type de ce nom ou de cette expression. En général, 
decl type indique exactement ce que nous avions prévu, mais il arrive parfois qu’elle 
donne des résultats qui risquent de nous laisser pantois et qui nous inciteront à 
consulter des sites de référence ou des FAQ. 
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Nous allons commencer avec des cas classiques, ceux sans surprises. Au contraire de 
ce qui se passe lors de la déduction de type pour les templates et auto (voir les conseils 1 
et 2), decl type se contente de répéter le type exact du nom ou de l’expression qui lui 
est donné : 


const Int i =0; 

II 

decl type ( i J donne const int. 

bool f (const Widget& w) ; 

II 

II 

decltype(w) donne const Widget&. 
decltype(f) donne bool (const klidgetH) 

struct Point 1 
int x, y; 

1; 

II 

II 

decltype(Point: :x) donne int. 
decl type( Poi nt : :y) donne int. 

Widget w; 

II 

decltype(w) donne Midget. 

if ( f (w) ) ... 

II 

decl ty pe ( f (w) ) donne bool. 

templ ate<typename T> 
class vector 1 
publ ic: 

II 

Version simplifiée de std::vector. 


T& operator[](std: :size_t index); 


I vector<int> v; // decitype(v) donne vector<int> . 

if ( v [ 0] = 0) ... Il deci ty pe( v [0] ) donne int&. 

Vous le constatez, aucune surprise. 

En C++1 1, decl type est probablement utilisé essentiellement pour la déclaration 
de templates d’une fonction dont le type de la valeur de retour dépend des types 
de ses paramètres. Par exemple, supposons que nous souhaitions écrire une fonction 
prenant en arguments un conteneur qui accepte l’indexation sous forme de crochets 
(c’est-à-dire « [] ») et un indice. Elle commence par authentifier l’utilisateur avant 
de retourner le résultat de l’indexation. Le type de retour de la fonction doit être 
identique à celui retourné par l’opération d’indexation. 

En invoquant operator[] sur un conteneur d’objets de type T, nous obtenons en 
général un élément de type T&. C’est par exemple le cas pour std : : deque, et presque 
toujours le cas pour std ; : vector. En revanche, pour std : : vector<bool >, operator [ ] 
ne renvoie pas un bool & mais un tout nouvel objet. Les détails de ce fonctionnement 
seront révélés au conseil 6. L’important ici est que le type retourné par la fonction 
operator[] d’un conteneur dépend de ce conteneur. 

Avec decl type, il est facile d’obtenir le bon fonctionnement. Voici une version mal 
dégrossie du template que nous aimerions écrire. Elle montre l’utilisation de decl type 
pour déterminer le type de la valeur de retour. Le template aura besoin de quelques 
ajustements, mais nous y reviendrons ultérieurement : 
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templ ateCtypename Container, typename Index) 
auto authAndAccess(Container& c. Index i) 

-> decl type ( c [ i ] ) 


Il Opérationnel mais 
Il a besoin d’être 
Il affiné. 


authenti cateUser( ) ; 
return c [ i ] ; 


La présence de auto avant le nom de la fonction n’a aucun rapport avec la 
déduction de type. Dans ce cas, ce mot clé indique que la syntaxe du « type de 
retour arrière » (trailing return type ) de C++1 1 est utilisée, autrement dit que le type 
de retour de la fonction sera déclaré après la liste de paramètres (après « -> ») Grâce 
au type de retour arrière, il est possible d’utiliser les paramètres de la fonction dans la 
spécification du type de retour. Par exemple, dans authAndAccess, nous spécifions le 
type de retour en fonction de c et de i . Si le type de la valeur de retour était placé 
avant le nom de la fonction, comme cela se fait de façon conventionnelle, c et i ne 
pourraient être utilisés car ils ne seraient pas encore déclarés. 

Avec cette déclaration, authAndAccess retourne le type renvoyé par operator[] 
lorsque cet opérateur est invoqué sur le conteneur passé en argument. Exactement ce 
que nous souhaitons. 

En C+ + 1 1, les types de retour des expressions lambda à instruction unique peuvent 
être déduits. C++ 14 va plus loin en autorisant cela pour toutes les expressions lambda 
et toutes les fonctions, y compris celles qui sont constituées de plusieurs instructions. 
Dans le cas de authAndAccess, cela signifie que nous pouvons, en C++14, omettre le 
type de retour arrière, pour ne laisser que le spécificateur auto du début. Dans une 
telle déclaration, l’utilisation de auto signifie que la déduction de type aura lieu. Plus 
précisément, elle signifie que le compilateur déduira le type de retour de la fonction à 
partir de son implémentation : 
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templ ate<typename Contai 
auto authAndAccess(Conta 
I 

authenti cateUser( ) ; 

return c[i ] ; 


er, typename Index) 
ner& c. Index i ) 


// Type de retour 


// C++ 14 ; 

II non totalement 
Il correct. 

déduit à parti r de c C i ] . 


Le conseil 2 explique que pour les fonctions qui spécifient leur type de retour avec 
auto, le compilateur met en place la déduction de type de template. Dans ce cas, cela 
pose un problème. Comme nous l’avons indiqué, pour la plupart des conteneurs de 
T, operator[] renvoie un T&, mais le conseil 1 explique que la déduction de type de 
template ignore le fait qu’une expression d’initialisation soit une référence. Voyons ce 
que cela signifie pour le code suivant : 

I std : :deque<int> d; 

authAndAccess(d, 5) = 10; // Authentifier un utilisateur, 



Copyright © 2016 Dunod. 



Chapitre 1. Déduction de type 


I II retourner d[5]. 

Il puis lui affecter 10. 

I I Ce code ne compile pas ! 

Dans cet exemple, d [ 5] renvoie un t&, mais la déduction de type auto sur la 
valeur de retour de authAndAccess omet la référence et lui détermine donc le type 
int. Puisque ce int est la valeur de retour d’une fonction, il s’agit d’une rvalue. Le 
code précédent tente donc d’affecter 10 à une rvalue de type int. Cette opération est 
interdite en C++ et la compilation du code échoue. 

Pour que authAndAccess fonctionne comme nous le souhaitons, nous devons 
employer la déduction de type decl type pour sa valeur de retour, c’est-à-dire préciser 
que authAndAccess doit renvoyer exactement le même type que celui renvoyé par 
l’expression c[i]. Les gardiens du C++, anticipant le besoin d’utiliser les règles de 
déduction de type decl type dans certains cas d’inférence des types, ont apporté cette 
possibilité en C++ 14 au travers du spécificateur decl type (auto). Ce qui pourrait 
sembler à première vue contradictoire (decl type et auto ?) a en réalité tout son sens : 
auto précise que le type doit être déduit, tandis que decl type indique que les règles 
decl type doivent être employées pour la déduction. Voici la nouvelle version de 
authAndAccess : 


templ ate<typename Container, typename Index) 

decltype(auto) 

authAndAccess(Container& c, Index i) 

I 

authenti cateüserC ) ; 
return c[i]; 


// C++ 14 ; 

// opérationnel mais 
// a encore besoin 
// d’être affiné. 


authAndAccess retourne désormais exactement ce que renvoie c[i ]. En particulier, 
dans le cas classique où c[i] renvoie un T&, authAndAccess retourne également un 
T&. Et, dans le cas moins fréquent où c[i ] retourne un objet, authAndAccess retourne 
aussi un objet. 

L’utilisation de decl type ( auto) ne se limite pas aux types de retour des fonctions. 
Il est également possible de l’employer dans la déclaration de variables de façon à 
appliquer les règles de déduction de type decl type à l’expression d’initialisation : 

Widget w ; 

const Widget& cw = w ; 

auto myWidgetl = cw; // Déduction de type auto : 

// myWidgetl est de type Widget. 

decltype(auto) myWidget2 = cw; Il Déduction de type decltype : 

Il myWidget2 est de type const Widget&. 

Nous l’avons mentionné, mais pas encore décrit. Examinons à présent la question 
du peaufinage de authAndAccess. Reprenons la déclaration de la version C++14 de 
authAndAccess : 



Conseil n° 3. Comprendre decltype 



I templ ateCtypename Container, typename Index) 

decl type(auto) authAndAccess(Container& c. Index i); 

Le conteneur est passé sous forme d’une référence lvalue à un non-const, car 
renvoyer une référence à un élément du conteneur permet à l’appelant de modifier 
celui-ci. Mais cela signifie qu’il est impossible de passer à cette fonction des conteneurs 
en rvalue. Les rvalues ne peuvent pas être liées à des références lvalue (excepté pour 
les références lvalue à un const, ce qui n’est pas le cas ici). 

Nous devons l’admettre, passer un conteneur en rvalue à authAndAccess est un cas 
limite. Puisqu’un conteneur rvalue est un objet temporaire, il sera détruit à la fin de 
l’instruction qui contient l’appel à authAndAccess. Toute référence à un élément de ce 
conteneur (ce que renverrait normalement authAndAccess) sera donc une référence 
dans le vide à la fin de l’instruction qui l’a créé. Cela dit, passer un objet temporaire à 
authAndAccess peut avoir un sens. L’appelant pourrait simplement souhaiter faire une 
copie d’un élément du conteneur temporaire, par exemple : 


std: :deque<std: :string> makeStri ngDequet ) ; // Fonction fabrique. 

// Faire une copie du 5e élément du deque retourné par 
// makeStringDeque. 

auto s = authAndAccess(makeStringDeque( ) , 5); 
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Pour qu’une telle utilisation soit possible, nous devons revoir la déclaration 
de authAndAccess afin qu’elle accepte les lvalues et les rvalues. La surcharge est 
une solution (une version déclarerait un paramètre de référence lvalue, l’autre, un 
paramètre de référence rvalue), mais nous aurions deux fonctions à maintenir. Pour 
éviter cela, une approche consiste à déclarer authAndAccess avec un paramètre de 
référence qui peut se lier aux lvalues et aux rvalues ; le conseil 24 explique que 
c’est justement le rôle des références universelles. Voici donc comment déclarer 
authAndAccess : 


templ ate<typename Container, typename Index) 
decltype(auto) authAndAccess(Container&& c, 

Index i ) ; 


// c est à présent 
// une référence 
// universelle. 


Dans ce template, nous ne connaissons pas le type de conteneur que nous 
manipulons et nous désignerons donc également le type des objets qui lui servent 
d’indices. Lorsque des objets de type inconnu sont passés par valeur, les performances 
en sont généralement impactées de façon négative, en raison de la copie inutile, du 
problème de découpage d’objet ( object slicing, décrit au conseil 41) et des moqueries de 
nos collègues. Toutefois, dans le cas des indices de conteneurs, suivre le modèle de la 
bibliothèque standard (par exemple dans operator[] pour std::string,std::vector 
et std: : deque) semble plutôt raisonnable. Nous allons donc conserver le passage par 
valeur. 
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Nous devons cependant revoir l’implémentation du template afin qu’il tienne 
compte de l’ avertissement conc ernant l’application de std: :forward aux références 
universelles (voir le conseil 25) : 


templ ate<typename Container, typename Index) // Version 

decl type(auto) // finale 

authAndAccess(Container&& c. Index i) // en C++14. 

{ 

authenticatellser( ) ; 

return std: :forward<Container>(c)[i ] : 

I 

Cette version répond parfaitement à nos besoins, mais elle exige un compilateur 
C+ + 14. Si vous n’en disposez pas, vous devrez vous tourner vers la version C++1 1 du 
template. Elles sont équivalentes, mais il vous faudra préciser le type de retour : 

templ ate<typename Container, typename Index) // Version 

auto // finale 

authAndAccess(Container&& c, Index i) // en C++11. 

-> decl type! std: :forward<Container)(c)[i ] ) 

{ 

authenti cateUser ( ) : 

return std: :forward<Container)(c)[i]; 

I 


Vous vous souvenez certainement de notre remarque au début de ce conseil : 
decl type renvoie presque toujours le type attendu, ce qui réserve rarement des surprises. 
Il est peu probable que vous rencontriez ces exceptions à la règle, sauf si vous 
développez des bibliothèques élaborées. 

Pour comprendre parfaitement le comportement de decl type, vous devez vous 
familiariser avec quelques cas particuliers. La plupart d’entre eux sont trop complexes 
pour être abordés dans cet ouvrage, mais nous allons en présenter un car cela nous 
fournira de précieuses informations sur decl type et son utilisation. 

En appliquant decl type à un nom, nous obtenons le type déclaré pour ce nom. Les 
noms sont des expressions lvalue, mais cela n’affecte pas le comportement de decl type. 
En revanche, lorsque les expressions lvalue sont plus compliquées que de simples noms, 
decl type s’assure que le type renvoyé est toujours une référence lvalue. Autrement dit, 
si une expression lvalue autre qu’un nom est de type T, decl type indique qu’elle est 
de type T&. Ce comportement n’a généralement pas d’impact, car le type de la plupart 
des expressions lvalue comprend un qualificatif de référence lvalue. Par exemple, les 
fonctions qui retournent des lvalues, renvoient toujours des références lvalue. 

Ce fonctionnement a cependant une implication qu’il est bon de connaître. 
Prenons l’instruction suivante : 

int x = 0; 

Puisque x est le nom d’une variable, decl type ( x ) renvoie i nt. En plaçant le nom 
x entre parenthèses, « (x) », nous obtenons une expression plus complexe. En tant 
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que nom, x est une lvalue et C++ définit l’expression (x) comme étant également 
une lvalue. decl type ( (x) ) renvoie donc i nt&. Le simple fait de placer des parenthèses 
autour d’un nom peut modifier le type renvoyé par decl type pour ce nom ! 

En C+ + 1 1 , ce fonctionnement n’est guère qu’une curiosité mais, placé dans le 
contexte de decl type ( auto) en C++14, il signifie qu’un changement d’apparence 
triviale dans la façon d’écrire une instruction return peut affecter le type déduit pour 
une fonction : 


decltype(auto) fl() 

I int x = 0; 

return x; // decltype(x) donne int, donc fl renvoie un int. 

I decltype(auto) f 2 ( ) 

int x = 0; 

return (x); // decl type( (x)) donne int&, donc f2 renvoie un int&. 

I 1 

Notez que non seulement f2 a un type de retour différent de fl, mais qu’elle 
renvoie également une référence à une variable locale ! C’est le genre de code qui 
conduit à coup sûr vers un comportement indéfini. 

En conclusion, vous aurez deviné qu’il faut faire très attention à l’utilisation de 
decltype(auto). Des détails semble-t-il insignifiants dans l’expression dont nous sou- 
haitons déduire le type peuvent avoir un effet sur le type renvoyé par decl type (auto). 
Pour être certain que le type déduit soit celui que nous attendons, les techniques 
décrites au conseil 4 doivent être adoptées. 

Cela dit, il faut garder une vision d’ensemble. Si decltype (seul ou avec auto) 
peut parfois occasionner des surprises sur la déduction du type, ce ne sera pas le cas 
dans une situation normale, decltype renvoie généralement le type attendu. C’est 
notamment le cas avec un nom car nous obtenons alors le type déclaré de ce nom. 


À retenir 

• decl type renvoie presque toujours le type d'une variable ou d'une expression 
sans le modifier. 

• Pour les expressions lvalue de type T autres que les noms, decl type indique 
toujours un type T&. 

• C++14 prend en charge decl type ( auto ), qui, à l'instar de auto, déduit le type 
à partir de son initialiseur, mais la déduction se fait conformément aux règles 

decl type. 
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CONSEIL N° 4. AFFICHER LES TYPES DÉDUITS 

Les outils à employer pour consulter les résultats de la déduction de type dépendent 
de la phase du processus de développement logiciel dans laquelle nous souhaitons 
cette information. Nous allons présenter trois contextes d’affichage des informations 
de déduction de type : pendant la saisie du code, pendant la compilation et pendant 
l’exécution. 


Éditeurs de code 

Dans les IDE, les éditeurs de code affichent souvent les types des entités d’un 
programme (comme des variables, des paramètres, des fonctions, etc.), par exemple 
en plaçant le curseur de la souris au-dessus d’une entité. Prenons le code suivant : 


const int theAnswer = 42; 

auto x = theAnswer; 

auto y = &theAnswer; 

Un éditeur de code indiquera probablement que le type déduit pour x est int et 

const i nt* pour y. 

Pour que cela fonctionne, le code doit être dans un état plus ou moins compilable, 
car si l’éditeur peut offrir cette fonctionnalité c’est en raison du compilateur C++ 
(tout au moins sa partie frontale) qui s’exécute au sein de l’IDE. Si le compilateur 
n’est pas en mesure de donner un sens à notre code et d’effectuer la déduction de type, 
il ne pourra pas afficher le type d’une entité. 

Dans le cas des types simples, comme int, l’information donnée par l’éditeur se 
révèle en général exacte. Cependant, et nous allons le voir, cette information sera 
sans doute moins utile lorsqu’elle concerne des types plus complexes. 


Diagnostics du compilateur 

Pour forcer un compilateur à indiquer le type qu’il a déduit, une solution efficace 
consiste à employer ce type de façon à déclencher des problèmes de compilation. 
Le message d’erreur qui décrit le problème affichera à coup sûr le type qui en est à 
l’origine. 

Par exemple, supposons que nous souhaitions connaître les types qui ont été 
déduits pour les variables x et y du code précédent. Nous commençons par déclarer 
un template de classe qui ne les définit pas : 


templ ate<typename T> 
class TD; 


// Déclaration uniquement pour TD ; 
// TD == "Type Displayer''. 
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Toute tentative d’instanciation de ce template produira un message d’erreur, car il 
n’y a aucune définition de template à instancier. Pour afficher les types de x et de y, il 
suffit d’essayer de créer une instance de TD avec leur type : 

I TD<decltype(x)> xType; // Obtenir des erreurs qui indiquent 

TD<decl type(y )> yType; // le type de x et de y. 

Nous utilisons des noms de variables de la forme nomDeLaVari abl eType, car ils 
permettent d’obtenir des messages d’erreur dans lesquels il est plus facile de trouver les 
informations que nous recherchons. Pour le code précédent, l’un de nos compilateurs a 
produit les diagnostics suivants (l’information de type qui nous intéresse est repérée) : 

error: aggregate 'TD<int> xType' has type incomplet and 
cannot be defined 

error: aggregate 'TD<const int *> yType' has type incomplet 
and cannot be defined 

Un autre compilateur apporte la même information, mais sous une forme diffé- 
rente : 

I error: 'xType' uses undefined class 'TD<int>' 

error: 'yType' uses undefined class 'TD<const int *>' 

Si l’on met de côté la question de la présentation, tous les compilateurs que nous 
avons testés génèrent des messages d’erreur qui contiennent des informations de type 
utiles. 


Affichage à l'exécution 

Afficher les informations de type à l’aide de printf (non que nous recommandions 
cette solution) n’est possible qu’au moment de l’exécution, mais elle apporte une plus 
grande liberté dans le format de la sortie. La difficulté sera de créer une représentation 
textuelle affichable du type qui nous intéresse. Simple pensez-vous peut-être, il suffit 
d’appeler typei d et std : : type_i nf o : : name à la rescousse. Pour afficher les types déduits 
pour x et y, vous pourriez être tenté d’écrire le code suivant : 


© 


I std::cout << typeid(x) .name( ) << '\n'; // Afficher les types 

std::cout << typeid(y) .name( ) << ' \n ' ; // de x et de y. 

Cette approche se fonde sur le fait que l’invocation de typei d sur un objet comme 
x ou y produit un objet std : : type_i nf o et que std : : type_i nfo offre la fonction name 
qui génère une représentation sous forme d’une chaîne de caractères C (c’est-à-dire 
un const char*) du nom du type. 

Rien ne garantit que les appels à std : : type_i nf o : : name retourneront un contenu 
sensé, mais les différentes implémentations font de leur mieux. Leur niveau de réussite 
varie. Les compilateurs GNU et Clang, par exemple, indiquent que le type de x 



Copyright © 2016 Dunod. 



Chapitre 1. Déduction de type 


est « i », et celui de y, « PKi ». Ces résultats trouvent leur sens lorsque l’on sait 
que, dans la sortie de ces compilateurs, « i » signifie « i nt » et que « P K » veut dire 
« pointeur sur konst const ». (Ces deux compilateurs disposent d’un outil, c++f i 1 1, 
pour « décrypter » ces types.) Le compilateur de Microsoft produit une sortie plus 
claire : « i nt » pour x et « i nt const * » pour y. 

Puisque les résultats obtenus sont corrects pour les types de x et de y, vous pourriez 
croire que le problème d’affichage du type est résolu. Ce serait un peu précipité. 
Prenons un exemple plus complexe : 


templ ate<typename T> 
void f(const T& param) ; 

std: :vector<Widget> createVec( ) ; 
const auto vw = createVecO; 

if ( !vw.empty( ) ) { 

f (&vw[0] ) ; 


// Fonction template 
// à appeler. 

// Fonction fabrique. 

// Initialiser vw avec la valeur 
// de retour de la fabrique. 

// Appeler f. 


Ce code implique un type défini par l’utilisateur (Widget), un conteneur STL 
(std : : vector) et une variable auto (vw). Il est plus représentatif des cas où une 
visibilité sur les types déduits par les compilateurs nous intéresse. Par exemple, il serait 
intéressant de connaître les types déterminés pour le paramètre de type T du template 
et pour le paramètre de fonction param dans f. 

Employer typei d pour résoudre le problème n’a rien de compliqué. Il suffit d’ajouter 
du code à f de façon à afficher les types concernés : 

templ ate<typename T> 

void f(const T& param) 

I 

using std: :cout; 

coût << "T = " << typeid(T) .name( ) << '\n'; // Afficher T. 

coût << "param = " << typeid(param) .name( ) << '\n'; // Afficher le 

// type de 

I // param. 

Voici l’affichage produit par l’exécution du code généré par les compilateurs GNU 
et Clang : 


T = PK6Wi dget 

param = PK6Wi dget 
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Pour ces compilateurs, nous savons déjà que P K signifie « pointeur sur const ». Il 
nous reste à comprendre la signification du chiffre 6. Il s’agit simplement du nombre 
de caractères présents dans le nom de la classe qui vient ensuite (Wi dget). En résumé, 
ces compilateurs nous indiquent que T et param sont de type const Widget*. 

Le compilateur de Microsoft est d’accord : 

I T = class Widget const * 
param = class Widget const * 

Trois compilateurs indépendants donnent la même information. Nous pouvons 
donc penser qu’elle est exacte. Mais voyons cela de plus près. Dans le template f , le 
type déclaré de param est const T&. Dans ce cas, n’est- il pas étrange que T et param 
aient le même type ? Si T était un int, par exemple, le type de param serait const i nt& 
— un type totalement différent. 

Malheureusement, les résultats de std: :type_info: :name ne sont pas fiables. Dans 
notre exemple, le type affiché par les trois compilateurs pour param n’est pas correct. 
Par ailleurs, il doit être incorrect car la spécification de std : : type_i nf o : : name exige 
que le type soit traité comme s’il était passé par valeur à la fonction template. Nous 
l’avons expliqué au conseil 1 , cela signifie que si le type est une référence, ce fait est 
ignoré, et si le type obtenu après l’omission de la référence est const (ou vol ati 1 e), 
cette caractéristique est également ignorée. C’est pourquoi le type de param (en réalité 
un const Widget * const &) est donné comme étant const Widget*. La notion de 
référence dans le type est tout d’abord retirée, puis le caractère const du pointeur 
résultant est oublié. 

Il est également malheureux que l’information de type affichée par les IDE ne soit 
pas plus fiable, ou tout au moins pas plus utilement fiable. Avec ce même exemple, 
voici ce qu’un éditeur a affiché comme type pour T : 

const 

std: :_Simple_types<std: : _W r a p_a 1 1 oc<s td : :_Vec_base_types<Widget, 
std: :allocator<Widget> >: :_Alloc>: :value_type>: :value_type * 

Et voici ce qu’il a donné pour pa ram : 

const std: :_Simple_types<. . .>: :value_type *const & 

Le résultat est moins intimidant que pour le type de T, mais les « ... » au milieu 
le rendent confus, jusqu’à ce que nous comprenions que l’IDE indique par-là « j’ai 
omis toute la partie qui concerne le type de T ». Avec un peu de chance, votre 
environnement de développement donnera de meilleurs résultats. 

Si vous préférez faire confiance aux bibliothèques plutôt qu’à la chance, vous serez 
content d’apprendre que là où std: :type_info: :name et les IDE peuvent échouer, 
la bibliothèque Boost Typelndex (souvent nommée Boost.Typelndex) a été conçue 
pour réussir. Elle ne fait pas partie du C++ standard, mais pas plus que les IDE ou les 
templates comme TD. Par ailleurs, le fait que les bibliothèques de Boost (disponibles 
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sur le site boost.com ) soient multiplates-formes, open-source et proposées avec une 
licence qui satisferait même le service juridique le plus pointilleux, signifie que le code 
qui les utilise est quasiment aussi portable que celui qui se fonde sur la bibliothèque 
standard. 

Voici comment notre fonction f peut afficher une information de type précise en 
utilisant la bibliothèque Boost.Typelndex : 


#1 ncl ude <boost/type_i ndex. hpp> 

templ ate<typename T> 
void f(const T& paraît) 

1 

using std: :cout; 

using boost: :typeindex: :type_id_with_cvr; 

// Afficher T. 
coût << "T = 

<< type_id_with_cvr<T>() .pretty_name( ) 

« '\n'; 

// Afficher ie type de paraît, 
coût << "parait = " 

<< type_id_wi th_cvr<decl type(param)>( ) .pretty_name( ) 
« '\n' ; 


Étudions le fonctionnement de cet exemple. Le template de fonction 
boost: :typeindex: :type_id_with_cvr prend un argument de type (celui à propos 
duquel nous souhaitons des informations) et ne retire pas les qualificatifs const, 
vol ati 1 e ou de référence (d’où la partie « wi th_cvr » dans le nom du template). Le 
résultat est un objet boost: :typeindex: :type_index, dont la fonction membre 
pretty_name génère un std : : st ri ng qui contient une représentation lisible du type. 

Avec cette implémentation de f , examinons de nouveau l’appel qui a donné une 
information de type incorrect pour param car fondée sur type i d : 

std: :vector<Widget> createVecO; // Fonction fabrique. 

const auto vw = createVecO; // Initialiser vw avec la valeur 

// de retour de la fabrique. 

if ( ! vw . empty ( ) ) { 

f ( &vw[0] ) ; // Appeler f. 

I 
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Avec les compilateurs GNU et Clang, Boost.Typelndex affiche le résultat (juste) 
suivant : 

I T = Widget const* 

param = Widget const* const& 

Celui obtenu avec les compilateurs de Microsoft est quasi identique : 


I T = class Widget const * 

param = class Widget const * const & 

Une telle uniformité est appréciable, mais il est important de ne pas oublier que les 
IDE, les messages d’erreur du compilateur et les bibliothèques comme Boost.Typelndex 
ne sont que des outils qui aideront à déterminer les types déduits par les compilateurs. 
Ils seront tous utiles, mais rien ne saura remplacer une parfaite compréhension des 
informations de déduction de type données dans les conseils 1 à 3. 

À retenir 

• Il est souvent possible d'afficher les types déduits en utilisant les IDE, les messages 
d'erreur du compilateur et la bibliothèque BoostTypelndex. 

• Les résultats obtenus avec certains outils risquent d'être ni utiles ni précis. Il est 
donc indispensable de comprendre les règles de déduction de type de C++. 
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En soi, auto est aussi simple qu’il puisse l’être, mais il est aussi plus subtil qu’il ne le 
paraît. Certes, il permet de faire des économies de saisie, mais il évite également les 
problèmes d’exactitude et de performances qui peuvent tourmenter les déclarations 
de type manuelles. Par ailleurs, certains des résultats de la déduction de type auto, 
bien que scrupuleusement conformes à l’algorithme prévu, sont, du point de vue du 
programmeur, tout simplement faux. Lorsque c’est le cas, il est important de savoir 
orienter auto vers la bonne réponse, car revenir à des déclarations de type manuelles 
est une solution qu’il est souvent préférable d’éviter. 

Ce court chapitre fait le tour des avantages et des inconvénients de auto. 
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CONSEIL N° 5. PRÉFÉRER AUTO AUX DÉCLARATIONS 
DE TYPES EXPLICITES 

Pourquoi faire compliqué quand on peut faire simple ? 

Int x; 

Mince, nous avons oublié d’initialiser x. Sa valeur est donc indéterminée. La 
variable peut avoir été fixée à zéro, mais cela dépend du contexte. Zut ! 

Peu importe, passons au plaisir simple de la déclaration d’une variable locale 
initialisée en déréférençant un itérateur : 

| template<typename It> // Algorithme pour appliquer un traitement 
void dwimCIt b, It e) // (dwim, pour "do what I mean") à tous 
( // les éléments entre b et e. 
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while (b != e) { 

typename std: :iterator_traits<It>: :value_type 

currVal ue = *b; 

I 

} 


Horrible! « typename std: : i t e r a t o r_t raits<It>: :value_type » pour exprimer le 
type de la valeur pointée par un itérateur ? Est-ce bien vrai ? Nous avons dû refouler 
le souvenir du plaisir que procurait ce type d’expression. Nous n’avons quand même 
pas écrit cela ! 

Quel bonheur simple de déclarer une variable locale dont le type est celui d’une 
fermeture ... D’accord, le type d’une fermeture n’est connu que du compilateur et ne 
peut donc pas être écrit. Mince ! 

Zut alors, la programmation en C++ n’est pas aussi agréable qu’elle le devrait ! 

L’a-t-elle vraiment été ? Quoi qu’il en soit, depuis C++ 11 et l’introduction de 
auto, toutes ces questions ne se posent plus. Puisque le type d’une variable auto est 
déduit à partir de son initialiseur, elle doit être initialisée. Autrement dit, dès lors que 
nous optons pour du C++ moderne, nous pouvons dire adieu à tout un ensemble de 
problèmes liés aux variables non initialisées : 

int xl ; // Potentiellement non initialisée. 

auto x2; // Erreur ! L’initialiseur est obligatoire. 

auto x3 - 0; // Parfait, la valeur de x est fixée. 

Nous évitons même les problèmes associés à la déclaration d’une variable locale 
dont la valeur est celle d’un itérateur déréférencé : 

templ ate<typename It> // Comme précédemment. 

void dwimdt b, It e) 

I 

while (b != e) { 
auto currVal ue = *b; 


Et, puisque auto se fonde sur la déduction de type (voir le conseil 2), il est possible 
de représenter des types connus uniquement du compilateur : 


auto derefUPLess = 

□ (const std: :unique. 

const std: :unique. 
( return *pl < *p2; 


II 

ptr<Widget>& pl. Il 
,ptr<Widget>& p2) Il 
; Il 


Fonction de comparaison 
de Widget 
désignés par 
des std: :unique_ptr. 


Plutôt intéressant ! C++ 14 va encore plus loin, car les paramètres des expressions 
lambda peuvent être définis avec auto : 
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auto derefLess = 
[](const auto& pl, 
const auto& p2) 

I return *pl < *p2; 


Il C++14 : fonction de comparaison 
Il de valeurs quelconques 
Il désignées par ce qui 
// ressemble à des pointeurs. 


Malgré l’intérêt de cette solution, vous pensez peut-être que nous n’avons pas 
vraiment besoin de a uto pour déclarer une variable qui contient une fermeture car nous 
pouvons employer un objet std : : functi on. C’est exact, mais ce n’est probablement 
pas ce à quoi vous pensiez. Vous vous demandez sans doute à présent ce qu’est un objet 
std: :function. 

std : : functi on est fourni par la bibliothèque standard de C++ 1 1 et ce template a 
pour objectif de généraliser la notion de pointeur de fonction. Cependant, alors que les 
pointeurs de fonctions ne peuvent désigner que des fonctions, les objets std : : functi on 
peuvent faire référence à n’importe quel objet invocable, c’est-à-dire tout ce qui peut 
être invoqué comme une fonction. Lors de la création d’un pointeur de fonction, nous 
devons spécifier le type de la fonction pointée (c’est-à-dire la signature des fonctions 
sur lesquelles nous voulons pointer). De la même manière, lors de la création d’un 
objet std : : functi on, nous devons préciser le type de la fonction référencée. Cela se 
fait au travers du paramètre de template de std : : functi on. Par exemple, pour déclarer 
un objet std : : functi on nommé f une qui peut faire référence à tout objet invocable 
qui aurait la signature suivante : 


bool (const std: :unique_ptr<Widget>&, // Signature C++11 pour 

const std: : uni que_pt r<Wi dget>& ) // une fonction de comparaison 

// de std: :unique_ptr<Widget>. 


il suffit d’écrire ce code : 


I std: :function<bool (const std: :unique_ptr<Widget>&, 

const std: :unique_ptr<Widget>&)> func; 

Puisque les expressions lambda impliquent des objets invocables, des fermetures 
peuvent être placées dans des objets std : : functi on. Nous pouvons donc déclarer la 
version C++1 1 de derefUPLess sans utiliser auto : 
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std: :function<bool (const std: :unique_ptr<Widget>&, 
const std: :unique_ptr<Widget>&)> 

derefUPLess = [ ] ( const std: :unique_ptr<Widget>& pl, 
const std: : unique_ptr<Widget>& p2) 

I return *pl < *p2; 1 ; 

Sans tenir compte de la verbosité syntaxique et de la nécessité de répéter les 
paramètres de type, l’utilisation de std: : functi on n’est pas identique à celle de 
auto. Une variable déclarée auto qui contient une fermeture a le même type que 
cette fermeture et n’utilise donc que la quantité de mémoire requise par la fermeture. 
Le type d’une variable déclarée std: : functi on et contenant une fermeture est une 
instanciation du template std: : functi on dont la taille est figée quelle que soit la 
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signature. Cette taille ne correspondra peut-être pas aux besoins de la fermeture à 
stocker. Dans ce cas, le constructeur de std : : f uncti on allouera une zone de mémoire 
sur le tas pour y placer la femreture. Par conséquent, l’objet std : : f uncti on consomme 
en général une quantité de mémoire plus importante que l’objet déclaré avec auto. 
Et, en raison des détails d’implémentation qui restreignent les fonctions i ni ine et 
conduisent à des appels de fonctions indirects, l’invocation d’une fermeture au travers 
d’un objet std: :f uncti on sera à coup sûr plus lente que son invocation au travers 
d’un objet déclaré avec auto. Autrement dit, la solution std : : f uncti on est en général 
plus coûteuse et plus lente que l’approche auto, sans compter qu’elle peut mener à des 
exceptions de dépassement de mémoire. Par ailleurs, nous l’avons vu dans les exemples 
précédents, il est plus simple de saisir « auto » que d’écrire le type de l’instanciation 
de std: :f uncti on. Dans le match entre auto et std: :f uncti on pour le stockage d’une 
fermeture, le grand gagnant est sans conteste auto. (Un argument comparable peut 
être développé lors du choix entre auto et std: :function pour stocker le résultat 
des appels à std: : b i n d , mais, au conseil 34, nous ferons tout pour vous convaincre 
d’utiliser les expressions lambda à la place de std : : bi nd.) 

Les avantages de auto ne se limitent pas à éviter les variables non initialisées, 
les déclarations verbeuses de variables et la possibilité de contenir directement des 
fermetures. 11 faut y ajouter l’élimination des problèmes que nous disons associés aux 
« raccourcis de types ». Voici un code que vous avez probablement déjà vu, voire écrit 
vous-même : 


I std::vector<int> v; 
unsigned sz = v.size( ) ; 

Officiellement, le type de la valeur de retour de v.sizeO est 
std : : vector<i nt> : : si ze_type, mais peu de développeurs le savent. La spécification 
de std : : vector<i nt> : : si ze_type stipule qu’il s’agit d’un type entier non signé et de 
nombreux programmeurs pensent que unsigned suffit et écrivent donc du code 
comparable au précédent. Les conséquences peuvent être assez intéressantes. Par 
exemple, sur un système Windows 32 bits, unsigned et std: : vectorCi nt>: :si ze_type 
ont la même taille, mais, sur la version 64 bits, un unsigned occupe 32 bits tandis 
qu’un std: : vector<i nt> : :size_type demande 64 bits. Autrement dit, un code 
opérationnel sur un système Windows 32 bits peut afficher un comportement 
incorrect sur un système Windows 64 bits. Par ailleurs, en cas de portage de 
l’application d’un système 32 bits vers un système 64 bits, qui souhaitera passer du 
temps sur de tels problèmes ? 

Grâce à auto, toutes ces interrogations disparaissent : 

auto sz = v.sizeO: // sz est de type std: :vector<int>: :size_type. 

Si vous n’êtes toujours pas convaincu de l’intérêt d’utiliser auto, étudions le code 
suivant : 
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std: :unordered_map<std: :string, int> m; 


for (const std: :pair<std: :string, int>& p : m) 
( 

Il Utiliser p. 


Il semble parfaitement raisonnable, mais il cache un problème. L’avez- vous trouvé ? 

Pour trouver ce qui ne va pas, il faut se rappeler que l’élément essentiel d’un 
std : : unorderedjnap est const. Par conséquent, le type de std::pair dans la 
table de hachage (ce qu’est réellement std : : unorderedjnap) est non pas 
std: :pair<std: :string, int>, mais std: : pa i r<const std::string, int>. 
Pourtant, ce n’est pas le type déclaré pour la variable p dans la boucle. Le 
compilateur va donc se débrouiller pour trouver une façon de convertir des objets 
std : : pa i r<const std : : stri ng , i nt> (ce que contient la table de hachage) en objets 
std : : pai r<std : : stri ng , i nt> (le type déclaré pour p). Pour cela, il va créer un objet 
temporaire du type auquel p veut se lier en copiant chaque objet de m, puis il va lier la 
référence p à cet objet temporaire. Celui-ci sera détruit à la fin de chaque itération de 
la boucle. Il est probable que vous soyez surpris par ce comportement car, en écrivant 
cette boucle, l’idée était certainement de lier simplement la référence p à chaque 
élément de m. 

Les erreurs de ce genre peuvent être évitées grâce à auto : 


for (const auto& p : m) 

( 

// Comme précédemment. 


u 

O 
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Non seulement ce code est plus efficace, mais il est également plus facile à saisir, 
sans oublier qu’il présente un autre intérêt. Si nous prenons l’adresse de p, nous sommes 
certains d’obtenir un pointeur sur un élément dans m. Avec le code qui n’utilise pas 
auto, nous obtenons un pointeur sur un objet temporaire, qui sera détruit à la fin de 
chaque itération de la boucle. 

Ces deux derniers exemples, écrire unsigned alors qu’il aurait fallu écrire 
std: : vector<int>: :size_type et écrire std: :pair<std: : string, int> à la place de 
std : : pai r<const std : : stri ng , i nt>, montrent bien qu’une spécification explicite des 
types peut conduire à des conversions implicites, ni voulues, ni attendues. En utilisant 
le type auto sur la variable cible, nous n’avons plus à nous inquiéter des incohérences 
entre le type déclaré de la variable et celui de l’expression d’initialisation. 

Les raisons de préférer auto à des déclarations de type explicites sont donc 
nombreuses. Pourtant, auto n’est pas parfait. Le type d’une variable auto est déduit de 
son expression d’initialisation et certaines de ces expressions ont des types qui sont 
ni anticipés ni souhaités. Les cas où cela se produit et la façon de les résoudre font 
l’objet des conseils 2 et 6. Nous ne les aborderons donc pas ici et, à la place, nous 
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allons nous intéresser à un autre problème de l’utilisation de auto en remplacement 
des déclarations de type classiques : la lisibilité du code source résultant. 

Soyez tranquille, auto est une option, non une obligation. Si, selon votre jugement 
professionnel, votre code est plus clair et plus facile à maintenir, ou meilleur de 
tout autre manière, en déclarant explicitement les types, vous pouvez poursuivre 
sur cette voie. Mais n’oubliez pas que C++ n’innove pas en adoptant ce qui est 
généralement connu dans le monde des langages de programmation sous le terme 
inférence de type. D’autres langages procéduraux à typage statique (comme O, D, 
Scala et Visual Basic) proposent une fonctionnalité plus ou moins équivalente, sans 
parler des langages fonctionnels à typage statique (comme ML, Haskell, OCaml, F#, 
etc.). Cette généralisation est en partie due au succès des langages à typage dynamique, 
comme Perl, Python et Ruby, dans lesquels les variables sont rarement typées de façon 
explicite. La communauté du développement logiciel possède une longue expérience 
de l’inférence de type et il a été démontré que cette technologie n’est en aucun 
cas contraire à la création et à la maintenance de larges bases de code de qualité 
industrielle. 

Certains développeurs sont perturbés par le fait que l’utilisation de auto retire 
toute possibilité de déterminer le type d’un objet par un simple examen du code 
source. Cependant, la capacité des IDE à afficher le type d’un objet tend à atténuer 
ce problème (même en tenant compte des difficultés mentionnées au conseil 4) et, 
dans de nombreux cas, une vue quelque peu abstraite du type d’un objet est aussi utile 
qu’une connaissance exacte. Par exemple, il suffit souvent de savoir qu’un objet est 
un conteneur, un compteur ou un pointeur intelligent, sans qu’il soit indispensable de 
connaître précisément le type de conteneur, de compteur ou de pointeur intelligent. 
Si les noms des variables sont bien choisis, cette information de type abstraite devrait 
presque toujours être disponible. 

Le fait est qu’écrire explicitement les types n’apporte souvent rien d’autre qu’une 
opportunité d’introduire des erreurs subtiles, que ce soit sur le plan de l’exactitude ou 
de l’efficacité, si ce n’est les deux. Par ailleurs, les types auto s’adaptent automatique- 
ment lorsque le type de l’expression d’initialisation change. Autrement dit, grâce à 
auto, le remaniement du code est plus facile. Par exemple, si une fonction déclare 
retourner un i nt et si nous décidons ultérieurement qu’un long conviendrait mieux, 
le code appelant se mettra automatiquement à jour lors de la compilation suivante, à 
condition que les résultats de l’appel de la fonction soient mémorisés dans des variables 
auto. En plaçant les résultats dans des variables déclarées explicitement comme des 
i nt, nous aurons à rechercher tous les appels de façon à les corriger. 


À retenir 

• Les variables auto doivent être initialisées, sont généralement immunisées contre 
les erreurs de typage qui peuvent mener à des problèmes de portabilité ou 
d'efficacité, peuvent faciliter le remaniement du code et demandent en général 
une saisie moindre que les types spécifiés explicitement. 

• Les variables auto sont sujettes aux risques décrits dans les conseils 2 et 6. 
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CONSEIL N° 6. OPTER POUR UN INITIALISEUR 
AU TYPE EXPLICITE LORSQUE AUTO DÉDUIT DES TYPES 
NON SOUHAITÉS 

Le conseil 5 explique que la déclaration de variables avec auto apporte plusieurs avan- 
tages techniques par rapport à la spécification explicite des types. Malheureusement, 
la déduction de type auto va parfois à gauche alors que nous voudrions qu’elle aille à 
droite. Supposons, par exemple, que nous ayons une fonction qui prend un Wi dget en 
paramètre et retourne un std : : vectorCbool >, dans lequel chaque bool indique si le 
Wi dget offre une certaine fonction : 

std: :vector<bool> features(const Wi dget& w) ; 

Supposons également que le bit 5 indique si le Wi dget dispose d’une priorité élevée. 
Nous pouvons alors écrire un code comparable au suivant : 

Wi dget w ; 

bool highPriority = features(w) [5] : // La priorité de w est-elle haute? 

processWidget(w, highPriority); // Manipuler w en fonction de 

// sa priorité. 

Ce code est correct et fonctionnera parfaitement. Mais apportons un changement 
d’apparence inoffensive en remplaçant le type explicite de hi ghPri ori ty par auto : 



I auto highPriority = features(w) [5] ; // La priorité de w est-elle 

// haute ? 

Dans ce cas, la situation change. Le code reste compilable, mais son comportement 
devient incertain : 

processWidget(w, highPriority); // Comportement indéfini ! 

Nous l’indiquons dans le commentaire, l’appel à processWi dget affiche à présent un 
comportement indéfini. Mais pour quelle raison ? La réponse risque de vous surprendre. 
Avec auto, highPriority n’est plus de type bool. Même si std: : vector<bool> contient 
conceptuellement des bool, la fonction operator[] pour std: :vector<bool> ne 
retourne pas une référence à un élément du conteneur (std: :vector: :operator[] 
retourne bien une référence, mais pour tous les types autres que bool ). À la place, elle 
retourne un objet de type std: : vector<bool > : : reference (une classe imbriquée dans 
std: : vector<bool >). 

La classe std: : vectoKbool > : : reference existe car std: : vectoKbool > doit repré- 
senter ses éléments bool sous forme compacte, un bit par bool . Cela pose un problème 
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à la fonction operator[] de std: : vector<bool >, car la fonction operator[] de 
std : : vector<T> est supposée retourner un T&, alors que les références à des bits 
sont interdites en C++. Puisqu’elle n’est pas en mesure de retourner un bool&, la 
fonction operator[] de std: : vectorCbool > renvoie un objet qui « sert » de bool&. 
Pour que cela fonctionne, des objets std : : vector<bool > : : ref erence doivent pouvoir 
être employés dans les mêmes contextes que des bool&. Parmi tous les éléments 
de std: : vectorCbool > : :reference qui participent à ce bon fonctionnement, nous 
trouvons une conversion implicite en bool . (Non en bool &, mais en bool. Expliquer 
l’ensemble des techniques employées par std : : vectorCbool > : : ref erence pour simuler 
le comportement d’un bool & nous éloignerait trop de notre propos. Signalons simple- 
ment que cette conversion implicite n’est qu’un élément d’un ensemble plus vaste.) 

En gardant cette information à l’esprit, examinons à nouveau cette partie du code 
d’origine : 

I bool highPriority = features(w)[5] ; // Déclarer explicitement 

// le type de highPriority. 

features renvoie ici un objet std : : vectorCbool >, sur lequel operator[] est invo- 
qué. operator[] retourne un objet std: : vectorCbool): : ref erence, qui est ensuite 
converti implicitement en un bool de façon à initialiser highPriority. Cette variable 
prend alors la valeur du bit 5 qui provient du std : : vectorCbool > renvoyé par features, 
exactement comme nous le voulons. 

Comparons ce fonctionnement à celui obtenu avec une déclaration auto pour 
hi ghPriori ty : 

I auto highPriority = features(w)[5] : // Déduire le type de 

// highPriority. 

À nouveau, features renvoie un objet std : : vectorCbool > sur lequel operator[] 
est invoqué. operator[] retourne encore un objet std: : vectorCbool): : ref erence, 
mais, cette fois-ci, auto en fait le type de highPriority par déduction, hi ghPri ori ty 
n’a pas du tout la valeur du bit 5 du std : : vectorCbool > retourné par features. 

La valeur qui lui est attribuée dépend de l’implémentation de 
std : : vectorCbool > : : reference. Dans une version, un tel objet contient un pointeur 
sur le mot machine qui comprend le bit référencé, ainsi que le décalage du bit dans ce 
mot. Voyons ce que cette implémentation de std : : vectorCbool > : : reference signifie 
pour l’initialisation de highPriority. 

L’appel à features renvoie un objet std: : vectorCbool) temporaire. Cet objet 
n’a pas de nom mais, pour faciliter les explications, appelons-le temp. operator[] 
est invoqué sur temp et l’objet std : : vectorCbool > : : reference renvoyé comprend un 
pointeur sur un mot dans la structure de données qui contient les bits gérés par temp, 
ainsi que le décalage qui correspond au bit 5 dans ce mot. highPriority est une copie 
de cet objet std : : vectorCbool > : : reference et comprend donc un pointeur sur un 
mot dans temp, ainsi que le décalage qui correspond au bit 5. Puisque temp est un 
objet temporaire, il est détruit à la fin de l’instruction. Par conséquent, highPriori ty 
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contient un pointeur dans le vide et c’est là la raison du comportement indéfini dans 
l’appel à processWidget : 

processWidget(w, highPriority) ; // Comportement indéfini ! 

// highPriority contient un 
// pointeur dans le vide ! 

std: : vectorCbool > : : reference est un exemple de classe proxy, c’est-à-dire une 
classe conçue pour émuler et étendre le comportement d’un autre type. Les classes 
proxy sont employées à divers objectifs. Par exemple, std : : vectorCbool > : : reference 
offre l’illusion que la fonction operator[] de std :: vectorCbool > retourne une 
référence sur un bit. De manière comparable, les types de pointeurs intelligents de 
la bibliothèque standard (voir le chapitre 4) sont des classes proxy qui greffent la 
gestion de ressources sur des pointeurs bruts. L’intérêt des classes proxy est reconnu. 
Le design pattern Proxy est même l’un des plus anciens membres du Panthéon des 
design patterns logiciels. 

Certaines classes proxy sont faites pour être vues par les clients. C’est notamment 
le cas de std: :shared_ptr et de std: :unique_ptr. D’autres agissent de manière 
plus ou moins visible, comme std :: vectorCbool >:: reference et son homologue 
std: : b i t s e t : : reference pour std: :bitset. 

Certaines classes des bibliothèques C++ appartiennent également à ce groupe et 
emploient une technique appelée templates d’expression. Ces bibliothèques ont été 
développées à l’origine dans le but d’améliorer l’efficacité des calculs numériques. Par 
exemple, étant donné une classe Matri x et les objets ml, m2, m3 et m4 de cette classe, 
l’expression 

Matrix sum = ml + m2 + m3 + m4; 

peut être calculée plus efficacement si la fonction operator+ de Matrix renvoie un 
proxy du résultat à la place du résultat lui-même. Autrement dit, operator+ pour deux 
objets Matri x retournera un objet d’une classe proxy comme SumCMatri x , Matri x> à la 
place d’un objet Matrix. Comme c’était le cas avec std: : vectorCbool >: : reference 
et bool, il existe une conversion implicite de la classe proxy vers Matrix, ce qui 
permet d’initialiser sum à partir de l’objet proxy généré par l’expression placée du 
côté droit du signe « = ». (Le type de cet objet encode habituellement l’intégralité de 
l’expression d’initialisation, c’est-à-dire quelque chose comme Sum<Sum<Sum<Matri x , 
Matri x> , Matri x> , Matri x>. Vous comprenez pourquoi il est préférable de masquer ce 
type au code client.) 

De façon générale, les classes proxy « invisibles » s’entendent mal avec auto. 
Les instances de ces classes sont rarement conçues pour vivre au-delà d’une seule 
instruction. Par conséquent, la création de variables de ces types va à l’encontre des 
hypothèses fondamentales de la conception d’une bibliothèque. C’est le cas avec 
std: : vector<bool >: : reference et nous avons vu que ne pas respecter ces hypothèses 
peut conduire à un comportement indéfini. 

Il vaut donc mieux éviter la forme de code suivante : 
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auto someVar = expression de type d’une classe proxy "invisible"; 

La question est donc de savoir si des objets proxy sont employés. Le logiciel qui les 
utilise n’annoncera probablement pas leur existence. Ils sont supposés être invisibles, 
tout au moins conceptuellement ! Et si nous les trouvons, devons-nous réellement 
abandonner auto et ses nombreux avantages décrits au conseil 5 ? 

Commençons par voir comment les trouver. Bien que les classes proxy « invisibles » 
soient conçues pour voler sous la couverture radar du programmeur dans une utilisation 
normale, les bibliothèques qui les utilisent les mentionnent souvent dans leur 
documentation. Plus nous sommes familiers des choix de conception des bibliothèques 
que nous utilisons, moins nous risquons d’être pris de court par l’emploi de proxy dans 
ces bibliothèques. 

Si la documentation manque de détails, les fichiers d’en-tête combleront ses 
lacunes. Le code source aura beaucoup de mal à dissimuler totalement les objets 
proxy. Ils sont habituellement retournés par des fonctions que les clients sont supposés 
appeler et les signatures de ces fonctions révèlent donc leur existence. Voici par 
exemple la définition de std: : vector<bool > : :operator[] : 

namespace std ( // Tiré de la bibliothèque standard de C++. 

template <class Allocator) 
class vectorCbool , Allocator) ( 
publ ic: 

class reference I ... }; 
reference operator[](size_type n ) ; 


En supposant que nous sachions que la fonction operator[] pour std::vector<T> 
renvoie normalement un T&, le type de retour inhabituel pour operator[] dans ce cas 
constitue un indice de l’utilisation d’une classe proxy. En examinant soigneusement 
les interfaces que nous utilisons, nous pouvons souvent découvrir l’existence de classes 
proxy. 

Dans la pratique, de nombreux développeurs découvrent l’utilisation de classes 
proxy uniquement lorsqu’ils tentent de comprendre les problèmes de compilation ou 
de déboguer des résultats erronés obtenus lors des tests unitaires. Quelle que soit la 
manière de les trouver, dès lors que auto déduit le type d’une classe proxy à la place 
du type qu’elle représente, la solution n’est pas d’abandonner auto car il n’est pas en 
cause. Le problème vient du fait que auto ne déduit pas le type que nous attendons. La 
solution est donc d’obliger une autre déduction de type. Pour cela, nous allons utiliser 
l’idiome de Yinitialiseur au type explicite. 

Cet idiome implique la déclaration d’une variable avec auto et le forçage du type 
de l’expression d’initialisation à celui qui doit être déduit par auto. Par exemple, voici 
comment le mettre en place pour imposer à hi ghPri ori ty le type bool : 



Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 6. Opter pour un initial iseur au type explicite lorsque auto déduit des types non souhaités 47 


TD 

O 


© 


auto highPriority = static_cast<bool>(features(w)[5]) ; 

features(w) [5] retourne encore un objet std : : vector<bool > : : reference, comme 
cela a toujours été le cas, mais la conversion de type change celui de l’expression 
en bool. auto attribue donc ce type à highPriority. Au moment de l’exécution, 
l’objet std: : vector<bool > : : reference renvoyé par std: : vector<bool>: :operator[] 
effectue sa conversion vers bool , au cours de laquelle le pointeur toujours valide sur 
le std: : vector<bool > renvoyé par features est déréférencé. Nous évitons ainsi le 
comportement indéfini précédent. L’indice 5 est ensuite appliqué aux bits ciblés par le 
pointeur et la valeur bool qui en résulte sert à initialiser hi ghPri ori ty. 

Voici comment employer l’idiome de l’initialiseur au type explicite dans le cas de 

Matri x : 

auto sum = static_cast<Matrix>(ml + m2 + m3 + m4); 

L’usage de cet idiome ne se limite pas aux initialiseurs conduisant à des types qui 
correspondent à des classes proxy. Il peut également se révéler utile pour indiquer la 
création délibérée d’une variable dont le type diffère de celui généré par l’expression 
d’initialisation. Supposons, par exemple, que nous ayons une fonction de calcul d’une 
valeur de tolérance : 

double cal cEpsi lon( ) ; // Retourner une valeur de tolérance. 

cal cEpsi 1 on retourne clairement un double, mais supposons que nous sachions 
que, dans notre application, la précision d’un fl oat convient et que la différence de 
taille entre les f 1 oat et les doubl e revêt une importance. Nous pouvons déclarer une 
variable fl oat pour contenir le résultat fourni par cal cEpsi 1 on : 

I f 1 oat ep = calcEpsilonC ) ; // Conversion implicite 

// de double vers float. 

Mais cette solution n’annonce pas clairement que nous diminuons volontairement 
la précision de la valeur retournée par la fonction. En revanche, une déclaration 
fondée sur l’idiome de Pinitialiseur au type explicite transmet ce message : 

auto ep = static_cast<float>(cal cEpsi 1 on { )) ; 

Un raisonnement comparable peut être tenu lorsqu’une expression en virgule 
flottante est mémorisée sous forme de valeur entière. Supposons que nous voulions 
calculer l’indice d’un élément dans un conteneur à l’aide d’itérateurs à accès aléatoire 
(par exemple std: :vector, std: :deque ou std: :array) et que nous recevions une 
valeur doubl e dans la plage 0 . 0 à 1 . 0 pour indiquer la place de l’élément souhaité dans 
le conteneur (0.5 représente le milieu du conteneur). Supposons de plus que nous 
soyons certains que l’indice résultant tiendra dans un i nt. Si le conteneur est c et si la 
valeur est d, nous pouvons calculer l’indice de la manière suivante : 
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int index = d * c.sizeC ) ; 

Cependant, cette solution n’indique pas clairement que la conversion en i nt de la 
valeur doubl e placée à droite est intentionnelle. Grâce à l’idiome de l’initialiseur au 
type explicite, les choses deviennent transparentes : 

auto index = static_cast<int>(d * c.sizeO); 


À retenir 

• Les types proxy « invisibles » peuvent conduire auto à la déduction du 
« mauvais » type pour une expression d'initialisation. 

• L'idiome de l'initialiseur au type explicite force auto à déduire le type qui est 
attendu. 





Sur le plan des fonctionnalités aux noms pompeux, C+ + 1 1 et C++ 14 ne sont pas en 
reste : auto, pointeurs intelligents, sémantique de déplacement, expressions lambda, 
concurrence, pour ne citer qu’elles. Mais elles sont si importantes qu’un chapitre est 
consacré à chacune d’elles et il est indispensable de les maîtriser. Toutefois, devenir 
un véritable programmeur en C++ moderne passe également par une suite de petites 
étapes. Chacune répond à des questions précises, qui se posent lors du passage du 
C++98 au C++ moderne. Quand devons-nous remplacer les parenthèses par des 
accolades lors de la création d’un objet ? Pourquoi les déclarations d’alias doivent être 
préférées aux typedef ? Quelles sont les différences entre constexpr et const ? Quel est 
le rapport entre les fonctions membres const et la sûreté vis-à-vis des threads ? Nous 
pourrions continuer cette liste encore longtemps. Une par une, ce chapitre fournira 
les réponses. 


CONSEIL N° 7. DIFFERENCIER ( ) ET {} 

LORS DE LA CRÉATION DES OBJETS 

Selon le point de vue, les différentes syntaxes proposées par C++ 1 1 pour l’initialisation 
d’un objet représentent soit une abondance de biens, soit une source de désordre. De 
façon générale, les valeurs d’initialisation peuvent être indiquées avec des parenthèses, 
un signe égal ou des accolades : 


Int x ( 0 ) ; 


int y = 0; 


// Initial îseur entre parenthèses. 
// Initial iseur après le signe . 


int z{ 0 }; 


// Initialiseur entre accolades. 
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Dans de nombreux cas, il est également possible d’utiliser un signe égal et des 
accolades : 

int z = { 0 }; // Initial i seur avec un signe et des accolades. 

Dans la suite de ce conseil, nous ignorerons généralement cette dernière possibilité 
car C++ la traite habituellement de la même manière que celle qui implique 
uniquement des accolades. 

Ceux qui pensent qu’il s’agit d’une « source de désordre » soulignent que l’initiali- 
sation avec un signe égal induit souvent en erreur les débutants, car ils pensent, à tort, 
y voir une affectation. Pour les types intégrés, comme int, la différence est théorique 
mais, pour les types définis par l’utilisateur, il est important de distinguer initialisation 
et affectation car elles font appel à des fonctions différentes : 

Widget wl; // Appeler le constructeur par défaut. 

Widget w2 = wl; // Pas d’affectation ; appel du constructeur de 

Il copie. 

wl = w2; Il Affectation ; appel de 1 ’ opérateur = de 

Il copie. 

Malgré les différentes syntaxes d’initialisation, il existe des cas où C++98 ne 
permettait pas d’exprimer l’initialisation souhaitée. Par exemple, il n’était pas possible 
d’indiquer directement qu’un conteneur STL devait être créé pour stocker un 
ensemble précis de valeurs (par exemple 1, 3 et 5). 

Pour résoudre le problème de confusion des multiples syntaxes d’initialisation, 
ainsi que l’impossibilité de prendre en charge tous les scénarios d’initialisation, C++ 1 1 
apporte l 'initialisation uniforme. Il s’agit d’une syntaxe d’initialisation unique qui, tout 
au moins dans le concept, peut être utilisée partout et peut tout exprimer. Elle se fonde 
sur les accolades et c’est pourquoi nous préférons l’expression initialisation à accolades. 
L’« initialisation uniforme » est un concept, l’« initialisation à accolades » est une 
construction syntaxique. 

L’initialisation à accolades nous permet d’exprimer ce qui était auparavant inexpri- 
mable. Grâce à cette syntaxe, il est facile de préciser le contenu initial d’un conteneur : 

std: :vector<int> v{ 1, 3, 5 }; // Le contenu initial de v est 1, 3, 5. 

Elle permet également de préciser les valeurs d’initialisation par défaut pour des 
données membres non statiques. Cette possibilité, apportée par C++11, peut aussi 
être obtenue par la syntaxe d’initialisation avec le signe « = », mais pas avec les 
parenthèses : 


class Widget I 
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private: 
int x{ 0 }; 
int y = 0; 
int z ( 0 ) ; 


Il Parfait, la valeur par défaut de x est 0. 
Il Également parfait. 

Il Erreur ! 


En revanche, les objets non copiables (par exemple std : : atomi c, voir le conseil 40) 
peuvent être initialisés avec des accolades ou des parenthèses, mais pas en utilisant le 
signe « = » : 


std: : atomi c<int> a i 1 { 0 }; // Parfait, 

std: : atomi c<i nt> ai2(0); // Parfait, 

std: :atomic<int> a i 3 = 0; // Erreur ! 

Vous devez à présent comprendre pourquoi l’initialisation à accolades est dite 
« uniforme ». Des trois façons de désigner une expression d’initialisation en C++, 
seules les accolades peuvent être employées partout. 

L’initialisation à accolades apporte une nouvelle fonctionnalité, en interdisant les 
conversions restrictives implicites entre les types intégrés. Si la valeur d’une expression 
placée dans un initialiseur à accolades ne peut pas s’exprimer de façon sûre dans le 
type de l’objet en cours d’initialisation, la compilation du code échoue : 

double x, y, z; 


int suml{ x + y + z }; Il Erreur ! Une somme de double peut ne pas 

Il pouvoir s’exprimer sous forme de int. 

Dans le cas d’une initialisation avec des parenthèses ou avec le signe « = », la 
conversion restrictive n’est pas vérifiée car cela remettrait en cause une grande 
quantité de code ancien : 

int sum2(x + y + z); // Valide (la valeur de l’expression est 

// tronquée pour tenir dans un int). 

int sum3 = x + y + z; // Idem. 

L’initialisation à accolades présente une autre caractéristique remarquable : elle 
résiste au problème de most vexing parse de C++. La règle de C++ selon laquelle 
tout ce qui peut être interprété comme une déclaration doit être interprété comme 
tel a un effet secondaire. Le problème de « most vexing parse » affecte en général 
les développeurs lorsqu’ils veulent construire par défaut un objet, mais en arrivent à 
déclarer à la place une fonction. L’origine du problème vient du fait qu’appeler un 
constructeur avec un argument peut se faire de la manière suivante : 
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I Widget wl(10); Il Appeler le constructeur de Widget avec 

Il l 'argument 10. 

Mais, si l’appel du constructeur de Wi dget se fait avec la même syntaxe mais sans 
aucun argument, nous déclarons en réalité une fonction à la place d’un objet : 

I Widget w2(); // Problème de "most vexing parse" ! Déclaration d’une 

// fonction nommée w2 qui retourne un Widget ! 

Puisque, dans la déclaration d’une fonction, la liste des paramètres ne peut pas être 
placée entre accolades, la construction par défaut d’un objet à l’aide des accolades 
n’est pas sujette à ce problème : 

Widget w3{}; // Appeler le constructeur de Widget sans argument. 

Nous avons beaucoup de bien à dire à propos de l’initialisation à accolades. Cette 
syntaxe peut être employée dans le plus grand nombre de contextes, elle évite les 
conversions restrictives implicites et n’est pas sujette au problème de « most vexing 
parse » de C+ + . Alors, pourquoi l’intitulé de ce conseil n’est-il pas comme « Préférer 
la syntaxe de l’initialisation à accolades » ? 

L’inconvénient de l’initialisation à accolades réside dans un comportement parfois 
surprenant. Ce comportement vient de la relation assez compliquée entre les initiali- 
seurs à accolades, les std : : i ni ti al i zer_l i st, et de la résolution de la surcharge de 
constructeur. Les interactions entre tous ces éléments peuvent conduire à du code 
qui semble réaliser une certaine action mais qui, en réalité, en effectue une autre. Par 
exemple, le conseil 2 explique que si l’initialisation d’une variable déclarée avec auto 
se fait avec des accolades, le type déduit est std : : i n i ti a 1 i zer_l i st, alors que d’autres 
façons de déclarer la variable avec les mêmes initialiseurs donneraient un type plus 
intuitif. Par conséquent, plus on aime auto, moins on est enthousiaste vis-à-vis de 
l’initialisation à accolades. 

Dans les appels aux constructeurs, les parenthèses et les accolades ont la même 
signification tant que des paramètres std : : i ni ti al i zer_l i st ne sont pas impliqués : 


class Widget I 
publ ic: 

Widget(int i, bool b); 
Widget(int i , double d) ; 


// Constructeurs qui ne déclarent pas des 
// paramètres std: : i n i t i a 1 i z e r_l i s t . 


Widget wl(10, true) ; 
Widget w2{10, true} : 
Widget w3(10, 5.0}; 
Widget w4{10, 5.0}; 


// 

// 

// 

// 


Invoque 

Invoque 

Invoque 

Invoque 


le premier constructeur, 
le premier constructeur, 
le second constructeur, 
le second constructeur. 
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En revanche, si un ou plusieurs constructeurs déclarent un paramètre de type 
std ::initial i zer_l i st, les appels fondés sur la syntaxe de l’initialisation à accolades 
préfèrent souvent les surcharges qui prennent des std: : initial izerjist. Si le 
compilateur trouve un moyen d’interpréter un appel avec un initialiseur à accolades 
en tant que constructeur qui prend un std : : i ni ti al i zer_l i st, alors il fera cette inter- 
prétation. Par exemple, étendons la classe Widget précédente avec un constructeur 
qui prend un std: : i ni ti al i zer_l i st<l ong double) : 

class Widget I 
publ i c : 

Widget(int i , bool b) ; 

Widget(int i , double d) : 

Wi dget ( std : : ini ti al izer_l i st<long double) il): Il Ajout. 

I 

Les Wi dget w2 et w4 sont alors créés en utilisant le nouveau constructeur, même si 
le type des éléments std "initial i zer_l i st (long doubl e) donne, en comparaison 
des constructeurs sans std : : i ni ti al i zer_l i st, une plus mauvaise correspondance 
pour les deux arguments ! Voyons cela : 

Widget wl(10, true); // Utilise les parenthèses et, comme 

// précédemment, appelle le premier 
// constructeur. 

Widget w2{10, true}; // Utilise des accolades, mais appelle à 

Il présent le constructeur 
Il std: :initializer_list (10 et true sont 
Il convertis en long double). 

Widget w3( 10 , 5.0): Il Utilise les parenthèses et, comme 

Il précédemment, appelle le second 
Il constructeur. 

Widget w4fl0, 5.01: Il Utilise des accolades, mais appelle à 

Il présent le constructeur 
Il std: -.initial izer_list ctor (10 et 5.0 sont 
Il convertis en long double). 

Même ce qui serait normalement une construction par copie et déplacement peut 
être détourné par des constructeurs std : : i ni ti al i zer_l i st : 

class Widget I 
publ ic: 

Widget(int i, bool b): // Comme précédemment. 

Widget(int i, double d); Il Comme précédemment. 

Widget(std: : i n i ti al izer_l i s t < 1 ong double) il): Il Comme précédemment. 

operator floatO const; Il Conversion en 

Il float. 



Il Comme précédemment. 
Il Comme précédemment. 
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Widget w5(w4); Il Avec des parenthèses, appel du constructeur 

Il de copie. 

Widget w6{w4}; Il Avec des accolades, appel du constructeur 

Il std: -.initial izer_li st (w4 est converti en 
Il float, et un float est converti en long double). 

Widget w7(std: :move(w4) ) ; Il Avec des parenthèses, appel du 

Il constructeur de déplacement. 

Widget w8{std: :move(w4)} ; Il Avec des accolades, appel du 

Il constructeur std: :initializer_list 
Il (même raison que pour w6). 


La détermination des compilateurs à faire correspondre les initialiseurs à accolades 
aux constructeurs qui prennent des std : : i n i ti a 1 i ze r_l i st est si forte qu’elle prévaut 
même si le constructeur std : : initial i zer_l i st de meilleure correspondance ne peut 
pas être appelé. Par exemple : 


class Widget I 
publ ic: 

Widget(int i, bool b); // Comme précédemment. 

Widget(int i, double d); // Comme précédemment. 


Widget(std: : initial izer_l ist<bool> il); //Le type de l’élément est 

// à présent bool . 


// 

// 


Aucune fonction de conversion 
implicite. 


Widget w{10, 5.0); // Erreur ! Conversions restrictives requises. 


Dans ce cas, le compilateur ignorera les deux premiers constructeurs (le deuxième 
offre une correspondance exacte pour les deux types d’arguments) et tentera d’invo- 
quer le constructeur qui prend un std : : i ni ti al i zer_l i stCbool >. Pour appeler ce 
constructeur, il faut convertir un int (10) et un double (5.0) en bool. Ces deux 
conversions sont restrictives (un bool ne peut pas représenter de façon précise l’une 
ou l’autre de ces valeurs) et sont interdites à l’intérieur des initialiseurs à accolades. 
L’appel est donc invalide et le code est refusé. 

Le compilateur se replie sur la résolution normale d’une surcharge uniquement 
lorsqu’il n’existe aucun moyen de convertir les types des arguments de Pinitialiseur 
à accolades vers le type indiqué dans un std: ; i nitial i zer_l i st. Par exemple, si 
nous remplaçons le constructeur std : : i ni ti al i zer_l i st<bool > par un construc- 
teur qui prend un std : : i ni ti al i zer_l i st<std : : stri ng>, les constructeurs sans 
std : ; i ni ti al i zer_l i st sont à nouveau éligibles car il n’existe aucun moyen de 
convertir des i nt et des bool en std : : stri ng : 
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class Widget ( 
public: 

Widget(int i, bool b); Il Comme précédemment. 

Widget(int i, double d ) ; Il Comme précédemment. 

// Un élément de std: : initial izer_list est à 
Il présent de type std::string. 

Widget (std: : ini ti al izer_l i s t <s td : : string) il ) ; 

Il Aucune fonction de conversion 
1; Il implicite. 


Wi 

dget 

wl(10. 

true) ; 

II 





II 

Wi 

dget 

w2{10, 

true] : 

II 





II 

Wi 

dget 

w3( 10 , 

5.0); 

II 





II 

Wi 

dget 

w4 {10, 

5.0}; 

II 





II 


Avec des parenthèses, appelle toujours 
le premier constructeur. 

Avec des accolades, appelle à présent 
le premier constructeur. 

Avec des parenthèses, appelle toujours 
le second constructeur. 

Avec des accolades, appelle à présent 
le second constructeur. 


T3 

O 

C 

D 

û 

VO 

tH 

O 

<N 

© 


en 


>* 

CL 

O 


U 


'<U 

C 

3 


U 

3 


D 

I 

fi 

G 

© 


Voilà qui nous amène proche du terme de notre étude des initialiseurs à accolades 
et de la surcharge de constructeur, mais il reste encore un cas intéressant. Supposons 
que nous utilisions un jeu d’accolades vide pour construire un objet qui prend en 
charge la construction par défaut et celle avec std : : i ni ti al i zer_l i st. Quel 
est le sens donné aux accolades vides ? Si elles signifient « aucun argument », 
nous obtenons une construction par défaut. En revanche, si elles signifient « un 
std : : i ni ti al i zer_l i st vide», alors nous obtenons une construction avec un 
std : : i ni ti al i zer_l i st dépourvu d’éléments. 

La règle est que les accolades vides représentent non pas un 
std : : i ni ti al i zer_l i st vide mais une absence d’argument. Nous obtenons donc une 
construction par défaut : 


class Widget { 
publ i c : 

WidgetO; // Constructeur par défaut. 

Widget(std: : ini tial izer_l ist<int> il): // Constructeur 

// std: : ini tial izer_list. 

// Aucune fonction de conversion implicite. 

1: 

Widget wl ; // Appelle le constructeur par défaut. 

Widget w2{}; // Appelle aussi le constructeur par défaut. 

Widget w3(); // "Most vexing parse”, déclare une fonction ! 
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Si nous voulons appeler un constructeur std : : i ni ti al i zer_l i st avec un 
std : : i ni ti al i zer_l i st vide, nous devons faire en sorte que les accolades vides 
soient un argument du constructeur. Pour cela, nous pouvons placer ces accolades 
vides à l’intérieur de parenthèses ou d’accolades qui délimitent le paramètre passé : 


Widget w4({}); // Appelle le constructeur std: : initial i z e r_l ist 

// avec une liste vide. 

Widget w5l {} ) : // Idem. 

À ce stade, en raison de toutes ces règles assez obscures sur les initialiseurs à 
accolades, les std: : initial izer_l ist et la surcharge de constructeur qui s’entre- 
mêlent dans votre esprit, vous vous demandez peut-être à quoi peuvent bien servir 
autant d’informations dans les développements classiques. À bien plus que vous 
l’imaginez sans doute, car std: :vector fait partie des classes directement affectées, 
std : : vector dispose d’un constructeur sans std : : i ni ti al i zer_l i st qui permet de 
préciser la taille de départ du conteneur et la valeur initiale de tous ses éléments. Mais 
il définit également un constructeur qui prend un std : : i ni ti al i zer_l i st permettant 
de préciser les valeurs initiales du conteneur. Si nous créons un std : : vector avec un 
type numérique (par exemple un std : : vector<i nt>) et si nous passons deux arguments 
au constructeur, les placer entre parenthèses ou entre accolades fait une énorme 
différence : 


std: :vector<int> vl(10, 20): // Utiliser le constructeur sans 

Il std: : initial izer_l ist : créer 10 
Il éléments std::vector, ayant tous 
Il la valeur 20. 

std: :vector<int> v2{10, 20}; Il Utiliser le constructeur 

Il std: -.initial izer_l ist : créer 

Il 2 éléments std::vector, l’un de valeur 

Il 10 et l’autre de valeur 20. 

Mais repartons de std: : vector et des détails des règles de résolution des paren- 
thèses, des accolades et de la surcharge de constructeur. Cette discussion a deux 
conclusions principales. Premièrement, en tant que développeur de classes, il faut 
savoir que si l’ensemble des constructeurs surchargés comprend une ou plusieurs fonc- 
tions qui prennent un std : : initial i zer_l i st, le code client qui utilise l’initialisation 
à accolades pourrait ne voir que les surcharges avec std: : i n i t i a 1 i z e r_l ist. Par 
conséquent, il est préférable de concevoir des constructeurs de sorte que la version 
surchargée appelée ne dépende pas de l’utilisation des parenthèses ou des accolades. 
Autrement dit, il faut apprendre de ce qui est à présent considéré comme une erreur 
de conception de l’interface de std : : vector et éviter de la reproduire dans nos classes. 

Si l’une de nos classes n’a pas de constructeur std: : i n i t i a 1 i z e r_l ist et si nous en 
ajoutons un, le code client qui utilise l’initialisation à accolades pourrait ne plus 
appeler les constructeurs sans std: : i n i t i a 1 i z e r_l ist mais invoquer la nouvelle 
fonction. Cette modification de comportement peut évidemment se rencontrer dès 
que nous ajoutons une nouvelle fonction à un ensemble de surcharges : les appels qui 



Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 7. Différencier () et {} lors de la création des objets 



TJ 

n 


conduisaient à l’invocation des anciennes surcharges risquent désormais d’appeler la 
nouvelle. Mais, dans le cas des surcharges de constructeur std : : i ni ti al i zer_l i st, la 
différence tient au fait qu’une surcharge std : : i ni ti al i zer_l i st non seulement entre 
en concurrence avec les autres surcharges mais les éclipse au point qu’elles risquent 
de ne plus être prises en compte. Il est donc indispensable de bien réfléchir avant 
d’ajouter de telles surcharges. 

Deuxièmement, en tant que client d’une classe, nous devons faire un choix réfléchi 
entre les parenthèses et les accolades lors de la création des objets. La plupart des 
développeurs finissent par adopter par défaut l’une des deux sortes de délimiteurs, 
en utilisant l’autre uniquement lorsque c’est nécessaire. Ceux qui optent pour les 
accolades sont attirés par leur grande diversité de contextes d’application, leur refus 
des conversions restrictives et leur immunité au problème de « most vexing parse ». 
Ces programmeurs savent que, dans certains cas, comme la création d’un std : : vector 
avec une taille donnée et une valeur d’élément initiale, les parenthèses sont requises. 
À l’opposé, les inconditionnels des parenthèses sont attirés par leur cohérence avec 
la syntaxe classique de C++98, l’absence du problème de la déduction auto qui 
donne un std : : i ni ti al izer_l i st et le fait que la création des objets ne sera pas 
malencontreusement détournée par les constructeurs std : : i ni ti al i zer_l i st. Ils 
acceptent que les accolades soient parfois indispensables, par exemple lors de la 
création d’un conteneur avec des valeurs spécifiques. Rien ne permet de faire pencher 
la balance d’un côté ou de l’autre. Nous vous conseillons donc de choisir une approche 
et de l’appliquer avec constance. 

Pour le développeur de templates, les hésitations entre une création d’objet avec 
des parenthèses ou des accolades peuvent être assez frustrantes car, en général, il 
est impossible de savoir celle qui doit être employée. Par exemple, supposons que 
nous voulions créer un objet de type quelconque à partir d’un nombre d’arguments 
quelconque. Conceptuellement, un template variadique apporte une réponse simple : 

templ ateCtypename T, // Type de l’objet à créer. 

typename... Ts> // Types des arguments à utiliser, 

void doSomeWork(Ts&&. . . params) 

( 


Créer un objet T local à partir de params... 


Il existe deux manières de remplacer la ligne de pseudo-code par du code réel (voir 
le conseil 25 pour une présentation de std: :forward) : 

T local Ob j ect (std : :forward<Ts>(params) ...) : // Avec des parenthèses. 

T localObjecttstd: :forward<Ts>(params) . . .}; // Avec des accolades. 

Examinons le code d’appel suivant : 
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I std: :vector<int> v; 

doSomeWork<std: :vector<int>>(10, 20) ; 

Si doSotneWork utilise des parenthèses dans la création de local Object, nous 
obtenons un std: :vector avec 10 éléments. S’il emploie des accolades, le résultat 
est un std : : vector avec 2 éléments. Quel est le bon comportement ? Le créateur de 
doSomeWork ne peut pas le savoir. Seul l’appelant sait ce qu’il veut. 

C’est précisément le problème auquel sont confrontées les fonctions 

std : :make_unique et std : :make_shared de la bibliothèque standard (voir le 
conseil 21). Elles l’ont résolu en utilisant les parenthèses de façon interne et en 
documentant ce choix dans leur interface 1 . 


À retenir 

• L'initialisation à accolades est la syntaxe d'initialisation qui peut être employée 
dans le plus grand nombre de situations. Elle évite les conversions restrictives et 
n'est pas sujette au problème de « most vexing parse » du C++. 

• Pendant la résolution de la surcharge de constructeur, les initialiseurs à accolades 
sont assortis à des paramètres std: : initial izer_list si cela est possible, 
même lorsque d'autres constructeurs donneraient potentiellement de meilleures 
correspondances. 

• La création d'un std: :vecto r<type numérique > avec deux arguments est un 
exemple dans lequel le choix entre les parenthèses et les accolades fait une 
différence importante. 

• Le choix entre les parenthèses et les accolades dans la création d'objets à 
l'intérieur de templates peut se révéler compliqué. 


CONSEIL N° 8. PRÉFÉRER NULLPTR À 0 ET À NULL 

Voici le nœud de l’affaire : le littéral 0 est de type i nt, non un pointeur. Lorsque C+ + 
trouve un 0 là où seul un pointeur peut être employé, il interprète ce 0 comme un 
pointeur nul, mais il s’agit d’une solution de repli. En C++, la règle de base veut que 0 
soit un i nt, non un pointeur. 

Sur un plan pratique, il en va de même pour NULL. Dans le détail, il existe toutefois 
quelques incertitudes sur le cas de NULL, car les implémentations peuvent lui donner 
un type entier autre que i nt (par exemple long). Ce n’est pas fréquent, mais peu 
importe car la question ici n’est pas le type précis de NULL, mais le fait que ni 0 ni NULL 
soient des pointeurs. 


1. Il existe des conceptions plus souples, qui permettent à l’appelant de savoir si des parenthèses 
ou des accolades doivent être employées dans les fonctions générées par un template. Pour de plus 
amples informations, consultez, sur le blog C++ tenu par Andrzej, l’article du 5 juin 2013 intitulé 
« Intuitive interface — Part I » ( http://akrzemil .uiordpress .com/ 20 1 3/06/05/intuitwe-interface-part--i/) . 
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En C++98, la principale conséquence de cette caractéristique était que la surcharge 
sur des pointeurs et des types entiers pouvait amener quelques surprises. En passant 0 
ou NU LL à ces surcharges, une surcharge avec pointeur n’était jamais invoquée : 


void 

f(int) ; 

II 

Trois s 

void 

f ( bool ) ; 



void 

f ( voi d* ) ; 



f (0) ; 


II 
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f (NULL) ; 

II 

Peut ne 
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L’incertitude concernant le comportement de f ( NU LL) vient de la latitude accordée 
aux implémentations vis-à-vis du type de NU LL. Par exemple, si NU LL est défini par OL 
(c’est-à-dire 0 de type 1 ong), l’appel est ambigu car les conversions d’un 1 ong en i nt, 
d’un 1 ong en bool et de OL en voi d* sont considérées aussi correctes l’une que l’autre. 
Le point intéressant dans cet appel vient de la contradiction entre la signification 
apparente du code source (« j’appelle f avec NU LL - le pointeur nul ») et son sens réel 
(« j’appelle f avec une sorte d’entier - non le pointeur nul »). C’est en raison de ce 
comportement contre-intuitif qu’il a été conseillé aux programmeurs C++98 d’éviter 
la surcharge sur des pointeurs et des entiers. Ces directives restent valides en C++1 1, 
car, malgré le conseil donné ici, il est probable que certains développeurs continueront 
d’employer 0 et NULL, alors que nul 1 ptr constitue un meilleur choix. 

L’intérêt de nul 1 ptr vient du fait qu’il n’est pas de type entier. Pour être honnête, 
il n’est pas non plus de type pointeur, mais il peut être vu comme un pointeur sur 
n’importe quel type. Le type réel de nul lptr est std: : nul 1 pt r_t et, par une jolie 
définition circulaire, std : : nul 1 ptr_t est défini comme étant le type de nul 1 ptr. Le 
type std : : nul 1 pt r_t convertit implicitement tous les types de pointeur bruts et c’est 
pourquoi nul 1 ptr agit comme s’il était un pointeur de n’importe quel type. 

En appelant la fonction surchargée f avec nul 1 ptr, nous invoquons la surcharge 
voi d* (c’est-à-dire celle avec pointeur), car nul 1 ptr ne peut pas être considéré comme 
un entier : 

f (nul 1 ptr ) ; // Appelle la surcharge f ( voi d* ) . 

En remplaçant 0 ou NULL par nul lptr, nous évitons donc les surprises de la 
résolution de la surcharge, mais ce n’est pas le seul avantage. Cette approche améliore 
également la clarté du code, notamment en présence de variables auto. Par exemple, 
supposons que l’extrait suivant provienne d’une base de code : 

auto resuit = fi ndRecord ( /* arguments */ ); 

if (resuit — 0) I 
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Si nous ne savons pas (ou ne pouvons pas trouver facilement) ce que renvoie 
fi ndRecord, il ne sera pas facile de déterminer si resuit est un pointeur ou un entier. 
En effet, 0 (utilisé dans la comparaison avec resul t) peut représenter l’un ou l’autre. 
En revanche, le code suivant n’est pas ambigu : 

auto resuit = findRecordi /* arguments */ ); 

if (resuit = nullptr) I 


resuit doit être un type pointeur. 

nullptr révèle tout son intérêt avec les templates. Supposons que nous ayons 
des fonctions qui doivent être appelées uniquement lorsque le mutex approprié a été 
verrouillé. Chaque fonction prend une sorte de pointeur différente : 


int fl(std: :shared_ptr<Widget> spw); // Appeler ces fonctions 

double f 2 ( s td : : uni que_pt r<Wi dget> upw); // lorsque le mutex 

bool f 3 ( Wi dget* pw) ; // approprié est verrouillé. 

Voici comment écrire un code appelant qui veut passer des pointeurs nuis : 


std::mutex flm, f2m, f 3m ; // Mutex pour fl, f2 et f3. 

using MuxGuard = // typedef de C++11 ; voir le conseil 9. 

std: :lock_guard<std: :mutex>; 


MuxGuard g(flm); 
auto resul t = f KO) ; 


// Verrouiller le mutex pour fl. 

// Passer 0 comme pointeur nul à fl. 
// Déverrouiller le mutex. 


MuxGuard g ( f 2m ) ; 
auto resuit = f 2 ( NU LL ) ; 


// Verrouiller le mutex pour f2. 

// Passer NULL comme pointeur nul à f2. 
// Déverrouiller le mutex. 


MuxGuard g ( f 3m ) ; 

auto resuit = f 3( nul! pt r ) ; 


// Verrouiller le mutex pour f3. 

// Passer nullptr comme pointeur nul à f3. 
// Déverrouiller le mutex. 


Il est regrettable de ne pas utiliser nullptr dans les deux premiers appels, mais le 
code est opérationnel et ce n’est pas négligeable. En revanche, la répétition dans le 
code appelant - verrouiller le mutex, appeler une fonction, déverrouiller le mutex — 
est plus gênante. Elle est même perturbante. C’est notamment pour éviter ce type 


Conseil n° 8. Préférer nul] ptr à 0 et à NULL 

de duplication dans le code source que les templates ont été conçus. Voyons donc 
comment les exploiter dans ce cas : 

templ ate<typename FuncType, 
typename MuxType, 
typename PtrType> 
auto lockAndCall (FuncType func, 

MuxType& mutex, 

PtrType ptr) -> decl type(func(ptr) ) 

( 

MuxGuard g(mutex); 
return func(ptr); 

I 

Si le type de retour de cette fonction (auto ... -> decl type(func(ptr )) vous 
questionne, consultez le conseil 3 pour comprendre ce qui se passe. Vous y découvrirez 
que, en C+ + 14, le type de retour peut se réduire à un simple decl type ( auto) : 

templ ateCtypename FuncType, 
typename MuxType, 
typename PtrType) 

decltype(auto) 1 ockAndCal 1 ( FuncType func, // C++14. 

MuxType& mutex, 

PtrType ptr) 

I 

MuxGuard g(mutex); 
return func(ptr); 

1 

En prenant le template 1 ockAndCal 1 , quelle que soit sa version, le code appelant 
peut s’écrire de la manière suivante : 

auto resultl = 1 ockAndCal! (fl , flm, 0); // Erreur ! 


auto result2 = 1 ockAndCal 1 ( f 2 , f2m, NULL); // Erreur ! 


auto result3 = 1 ockAndCal 1 ( f 3 , f3m, nul 1 ptr ) ; // Parfait. 

Bien que le code puisse être écrit ainsi, deux des trois cas ne compilent pas. Dans le 
premier appel, le problème vient du fait que le passage de 0 à 1 ockAndCal 1 déclenche 
la déduction de type de template afin de déterminer le type de 0. Il s’agit toujours d’un 
i nt, qui est donc le type du paramètre ptr à l’intérieur de cet appel à 1 ockAndCal 1 . 
Malheureusement, cela implique qu’un int est passé à func lors de l’appel à cette 
fonction dans 1 ockAndCal 1 , alors que ce type n’est pas compatible avec le paramètre 
std: :shared_ptr<Widget> attendu par fl. Le 0 indiqué dans l’appel à lockAndCall 
était supposé représenter un pointeur nul, alors qu’en réalité un i nt ordinaire a été 
passé. Tenter de passer ce int à fl en tant que std : : s h a red_pt r <W i dget> déclenche 
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une erreur de type. L’appel à 1 ockAndCal 1 avec 0 échoue, car, dans le template, un i nt 
est passé à une fonction qui exige un std : : shared_ptr<Wi dget>. 

L’analyse de l’appel avec NULL est comparable. Lorsque NULL est passé à 1 ockAndCal 1 , 
le type déduit pour le paramètre est un entier et une erreur de type se produit 
lorsque ptr (un i nt ou équivalent) est passé à f 2, car cette fonction attend un 
std: : unique_ptr<Widget>. 

À l’opposé, l’appel fondé sur nul 1 ptr ne pose aucun problème. Lorsque nul 1 ptr 
est passé à 1 ockAndCal 1 , le type déduit pour ptr est std : : nul 1 ptr_t. Lorsque ptr est 
passé à f 3, une conversion implicite de std : : nul 1 ptr_t vers Wi dget* est effectuée. En 
effet, un std : : nul 1 ptr_t peut implicitement être converti en n’importe quel type de 
pointeur. 

Le fait que la déduction de type de template détermine le « mauvais » type pour 
0 et NULL (c’est-à-dire leur véritable type plutôt que leur représentation annexe d’un 
pointeur nul) constitue une raison irréfutable de remplacer 0 ou NULL par nul 1 ptr 
pour faire référence à un pointeur nul. Avec nul 1 ptr, les templates ne posent aucun 
problème particulier. Si l’on ajoute à cela le fait que nul 1 ptr ne souffre pas des surprises 
amenées par la surcharge avec 0 et NULL, le dossier est clos. Si vous devez faire référence 
à un pointeur nul, utilisez non pas 0 ou NULL mais nul 1 ptr. 


À retenir 

• Préférer nul 1 ptr à 0 et à NULL. 

• Éviter la surcharge sur des types entiers et des pointeurs. 


CONSEIL N° 9. PRÉFÉRER LES DÉCLARATIONS D'ALIAS 

AUX TYPEDEF 

Nous sommes certains que vous pensez vous aussi que l’utilisation des 
conteneurs STL est une bonne idée, et nous espérons que le conseil 18 saura 
vous convaincre qu’utiliser std : : unique_ptr l’est également. Cependant, nous 
sommes convaincus que personne n’aime saisir plusieurs fois des types comme 
std: :unique_ptr<std: :unordered_map<std: : string, std: :string>>. Rien que d’y 
penser, le risque de souffrir du syndrome du canal carpien augmente. 

Pour éviter de tels soucis médicaux, il suffit de se tourner vers typedef : 


typedef 

std: : unique_ptr<std : :unordered_map<std: :string, std: :strinq>> 
UPtrMapSS; 


Mais les typedef font beaucoup trop C++98. Ils sont effectivement reconnus en 
C+ + 1 1 , mais cette version du C++ offre les déclarations d’alias : 
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I using UPtrMapSS = 

std : :unique_ptr<std: : unordered_map<std : :string, std: :string>>; 

Puisque typedef et une déclaration d’alias produisent exactement le même résultat, 
il est légitime de se demander s’il existe une véritable raison technique de préférer l’un 
à l’autre. 

Elle existe, mais, avant de la présenter, mentionnons que de nombreux program- 
meurs trouvent que la déclaration d’alias est plus commode lorsque les types impliquent 
des pointeurs de fonctions : 


// FP est synonyme d’un pointeur sur une fonction qui attend un int 
// et un const std: :string&, et qui n’a pas de valeur de retour, 
typedef void (*FP)(int, const std : : st ri ng& ) ; // Avec typedef. 

// Même chose que précédemment. 

using FP = void (*)(int, const std: : s tr i ng& ) : // Avec une déclaration 

// d’alias. 


-o 

O 


© 


Évidemment, aucune des deux formes n’est particulièrement difficile à comprendre 
et peu de développeurs passent beaucoup de temps à gérer des synonymes de pointeurs 
de fonctions. Ce n’est donc pas la raison de préférer les déclarations d’alias aux 
typedef. 

En revanche, les templates apportent une très bonne raison. Plus précisément, les 
déclarations d’alias peuvent être transformées en templates (auquel cas, elles sont 
appelées alias de template), ce qui est impossible avec typedef. Les programmeurs en 
C+ + 11 disposent alors d’un mécanisme simple pour écrire des expressions qui, en 
C++98, nécessitent une combinaison de typedef imbriqués dans des struct définis 
comme des templates. Supposons, par exemple, que nous voulions définir un synonyme 
pour une liste chaînée qui utilise un allocateur personnalisé, MyAl 1 oc. Avec un alias 
de template, c’est un jeu d’enfant : 

templ ate<typename T> // MyAllocList<T> 

using MyAl 1 oc Li st = std : : 1 i s t <T , MyAlloc<T>>; // est synonyme de 

// std : : 1 i st<T, 

// MyAl 1 oc<T>> . 

MyAl locList<Widget> Iw; // Code client. 

Avec typedef, il faut tout constituer à partir de zéro : 


templ ate<typename T> // MyAl 1 ocList<T>: : type 

struct MyAl 1 oc Li st { // est synonyme de 

typedef std : : 1 i s t<T , MyAlloc<T>> type; // std: : 1 i s t <T , MyAlloc<T>> 

} 

MyAl 1 ocLi st<Wi dget> :: type 1 w ; // Code client. 
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Cela s’aggrave si nous souhaitons utiliser typedef à l’intérieur d’un template dans le 
but de créer une liste chaînée qui contient des objets du type spécifié par un paramètre 
de template. 11 faut alors placer typename avant le nom typedef : 


templ ate<typename T> 
class Widget I 
pri vate: 

typename MyAl 1 ocli st<T> : : type list; 


// Widget<T> contient 
// un MyAl 1 ocList<T> 

// comme donnée member. 


Dans cet exemple, MyAl 1 oc Li st<T> : : type fait référence à un type qui dépend du 
paramètre de type du template (T). MyAl 1 oc Li st<T>: : type est donc un type dépendant, 
et l’une des nombreuses règles sympathiques de C++ stipule que les noms des types 
dépendants doivent être précédés de typename. 


Si la définition de MyAl 1 ocLi st se fait sous forme d’un alias de template, typename 
n’est plus nécessaire, tout comme le suffixe « : : type » plutôt encombrant : 


templ ate<typename T> 

using MyAllocList = s td : : 1 i st<T , MyAlloc<T>>; // Comme précédemment. 

templ ate<typename T> 
class Widget I 
pri vate: 

MyAl 1 ocLi st<T> list; // Plus de "typename", 

// ni de "::type". 


De notre point de vue, on pourrait penser que MyAl 1 ocLi st<T> (l’utilisation de l’alias 
de template) est aussi dépendant du paramètre de template T que MyAl 1 oc Li st<T> : : type 
(l’utilisation du typedef imbriqué), mais nous ne sommes pas un compilateur. Lorsque 
le compilateur traite le template Widget et rencontre l’utilisation de MyAl 1 ocList<T> 
(l’utilisation de l’alias de template), il sait que MyAl 1 ocLi st<T> correspond au nom d’un 
type car MyAl 1 ocLi st est un alias de template : il doit nommer un type. MyAl 1 ocLi st<T> 
est donc un type non dépendant et le spécificateur typename n’est ni requis ni autorisé. 

En revanche, lorsque le compilateur rencontre MyAl 1 ocLi st<T> : :type (l’utilisa- 
tion du typedef imbriqué) dans le template de Widget, il ne peut pas savoir avec 
certitude qu’il correspond au nom d’un type. En effet, il s’agit d’une spécialisation de 
MyAl 1 ocLi st qui n’a pas encore été vue et où MyAl 1 ocLi st<T> : ; type fait référence à 
autre chose qu’un type. Cela peut sembler insensé, mais il ne faut pas reprocher cette 
possibilité au compilateur. Ce sont des personnes en chair et en os qui sont réputées 
produire un tel code. 

Par exemple, un programmeur mal avisé pourrait avoir concocté le code suivant : 


class Wine I ... ); 
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templ ate<> 

II 

class MyAl 1 ocLi st<Wine> { 

II 

private: 

enum class WineType 

II 
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II 

WineType type; 
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Vous le constatez, MyAl 1 oc Li s t < W i ne> : : type ne fait pas référence à un type. Si une 
instance de Wi dget est créée avec un Wi ne, le MyAl 1 ocLi st<T> : : type à l’intérieur du 
template Wi dget fait référence à une donnée membre, non à un type. Dans le template 
Wi dget, que MyAl 1 ocLi st<T> : : type fasse ou non référence à un type dépend de T et 
c’est pourquoi le compilateur insiste pour que nous confirmions qu’il s’agit d’un type 
en ajoutant typename. 

Si vous vous êtes déjà essayé à la métaprogrammation avec des templates (TMP, 
template metaprogramming), vous vous êtes certainement heurté à la nécessité de 
prendre des paramètres de type de template et d’en créer des versions revues. Par 
exemple, étant donné un type T, vous pourriez vouloir retirer les qualificatifs const ou 
de référence présents dans T, et ainsi transformer const std : : stri ng& en std : : s t ri ng. 
Ou bien, vous pourriez souhaiter ajouter const à un type ou le transformer en référence 
Ivalue, par exemple convertir Wi dget en const Wi dget ou en W i d g e t & . (Si vous n’avez 
jamais utilisé la TMP, c’est vraiment dommage car, pour être un programmeur C++ 
réellement efficace, vous devrez vous familiariser au moins avec les bases de cet aspect 
du C++. Vous trouverez des exemples de TMP, notamment les transformations de type 
précédentes, aux conseils 23 et 27.) 

C++ 11 apportent les outils qui permettent d’effectuer ces transformations au 
travers des traits de type. Il s’agit d’un assortiment de templates dans l’en-tête 
<type_t rai ts>. Cet en-tête en comprend des dizaines, tous ne réalisant pas des 
transformations de types, mais ceux qui le font ont une interface connue. Etant donné 
un type T auquel nous souhaitons appliquer une transformation, le type résultant est 
std: : transformation <T>: Type. Par exemple : 

std: :remove_const<T>: Type II Obtenir T à partir de const T. 

std: :remove_reference<T>: Type // Obtenir T à partir de T& et de T&&. 

std: :add_lvalue_reference<T>: Type // Obtenir T& à partir de T. 

Les commentaires résument simplement ce que font les transformations ; il ne faut 
donc pas trop les prendre au pied de la lettre. Avant de les employer dans un projet, 
examinez leurs spécifications détaillées. 

Nous n’avons pas pour objectif ici de présenter les traits de type. Notons simple- 
ment que l’application de ces transformations conduit à l’ajout de « : : type » à la fin 
de chaque utilisation. Si elles doivent être appliquées à un paramètre de type dans un 
template (ce qui correspond à leur emploi classique dans du code réel), il faut faire 



Copyright © 2016 Dunod. 



Chapitre 3. Vers un C++ moderne 


précéder chaque utilisation par typename. Ces deux contraintes syntaxiques viennent 
du fait que les traits de type en C+ + 11 sont implémentés sous forme de typedef 
imbriqués dans des templates de struct. Vous avez bien lu, ils sont mis en œuvre avec 
la technique que nous disons inférieure à celle des alias de templates ! 

La raison en est historique, mais nous ne la donnerons pas. Le comité de norma- 
lisation a reconnu tardivement que les alias de templates constituent une meilleure 
solution et a inclus dans C++ 14 des templates pour toutes les transformations de 
type de C++11. Les alias ont une forme commune : pour chaque transformation 
std: : transforma tion<J>: : type de C++11, il existe un alias de template C++14 
correspondant nommé std : : transformation _t. Voici quelques exemples : 


std: : remove_const<T>: :type 
std : : remove_const_t<T> 


Il C++11 : const T — » T. 
Il Équivalent C++14. 


std : : remove_reference<T> : : type II C++11 : T&/T&& — *• T. 

std: : remove_reference_t<T> Il Équivalent C++14. 


std: :add_lvalue_reference<T>: :type II C++11 : T — > T&. 
std: :add_lvalue_reference_t<T> Il Équivalent C++14. 


Les constructions C++1 1 restent valides en C+ + 14, mais il n’y a aucune raison de 
les utiliser. Si aucun compilateur C++ 14 n’est pas disponible, écrire nous-mêmes les 
alias de templates est un jeu d’enfant. Cela nécessite uniquement les caractéristiques 
du langage C+ + 1 1, et reproduire un motif est à la portée de n’importe qui. Il est même 
possible de récupérer une copie électronique de la norme C+ + 14 et de procéder par 
copier-coller. Voici un point de départ : 


template <class T> 

using remove_const_t = typename remove_const<T>: :type; 
template <class T> 

using remove_reference_t = typename remove_reference<T>: :type; 
template <class T> 

using add_l val ue_reference_t = typename add_lvalue_reference<T>: : type ; 


Difficile de faire plus simple. 


À retenir 

• Les typedef sont incompatibles avec les templates, contrairement aux déclara- 
tions d'alias. 

• Les alias de templates permettent d'éviter le suffixe « ::type » et, dans les 
templates, le préfixe « typename » souvent requis pour faire référence aux 

typedef. 

• C++1 4 apporte des alias de templates pour toutes les transformations effectuées 
par des traits de type en C++1 1 . 




Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 10. Préférer les enum délimités aux enum non délimités 



CONSEIL N° 10. PRÉFÉRER LES ENUM DÉLIMITÉS 
AUX ENUM NON DÉLIMITÉS 

En règle générale, la déclaration d’un nom à l’intérieur d’accolades limite la visibilité 
de ce nom à la portée fixée par ces accolades. Ce n’est pas le cas pour les énumérateurs 
déclarés avec les enum dans le style de C++98. Les noms de ces énumérateurs 
appartiennent à la portée dans laquelle se trouve l’enum. Cela signifie qu’aucun autre 
élément dans cette portée ne peut prendre le même nom. Par exemple : 


-o 

n 


© 


enum Color | black, white, red I; // black, white et red sont dans 

// la même portée que Color. 

auto white = f al se ; // Erreur ! white est déjà déclaré 

// dans cette portée. 

Ces énumérations sont dites non délimitées, car les noms des énumérateurs ont 
la même portée que celle de leur définition enum. Avec leurs nouveaux homologues 
C+ + 1 1 , les énumérations délimitées (ou enum fortement typé), les noms ne sortent pas 
des accolades : 

enum class Color I black, white, red I; // black, white et red sont 

// limités à Color. 

Il Valide, aucun autre 
Il "white” dans la portée. 

Il Erreur ! Aucune énumérateur nommé 
// "white" dans cette portée. 

Il Valide. 

Il Valide (et en accord avec 
Il le conseil 5). 

Puisque les enum délimités sont déclarés avec « enum cl a s s », ils sont parfois appelés 
classe enum. 

La diminution de la pollution de l’espace de noms obtenue grâce aux énumérations 
délimitées suffit déjà à les préférer aux énumérations non délimitées. Mais elles ont 
également un autre avantage : leurs énumérateurs sont plus fortement typés. Les 
énumérateurs des enum non délimités sont implicitement convertis en types entiers 
(et, à partir de là, en types à virgule flottante). Les parodies sémantiques suivantes 
sont donc parfaitement valides : 

enum Color | black, white, red ); // enum non délimité. 

std: : vector<std: :size_t> // Fonction qui retourne les 

primeFactors(std: :size_t x); // facteurs premiers de x. 


auto white = fal se; 

Color c = white; 

Color c = Color: :white; 
auto c = Color: :white; 
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Color c = red; 



if (c < 14.5) ( 

II 

Comparer un Color à un double (!) 

auto factors = 

II 

Déterminer les facteurs premiers 

primeFactors(c) ; 

II 

d’un Color (!) 


En revanche, en ajoutant simplement « cl ass » après « enum », l’énumération non 
délimitée devient une énumération délimitée et le fonctionnement change totalement. 
Dans un enum délimité, les énumérateurs ne sont plus convertis implicitement en un 
autre type : 


enum class Color I black, white, red }; // enum à présent délimité. 


Color c = Color: : red ; 


// Comme précédemment, mais avec 
// un qualificateur de portée. 


if (c < 14.5) 


// Erreur ! Impossible de comparer 
// un Color et un double. 


auto factors = 
primeFactors(c) ; 


Il Erreur ! Impossible de passer un Color 
Il à une fonction qui attend un std::size_t. 


Pour effectuer une conversion intentionnelle d’un Color vers un autre type, il faut 
employer la méthode habituelle qui permet de soumettre le système de typage à notre 
bon vouloir : 


if (static_cast<double>(c) < 14.5) I // Code bizarre mais valide. 


auto factors = 

primeFactors(static_cast<std: :size_t>(c) ) ; 


// Suspect, mais la 
// compilation réussit. 


On pourrait également trouver un troisième avantage aux énumérations délimitées 
par rapport aux énumérations non délimitées. Il est en effet possible de les utiliser 
avec une déclaration anticipée, c’est-à-dire de déclarer leur nom sans préciser leurs 
énumérateurs : 

I enum Color; // Erreur ! 

enum class Color; // Valide. 

Cela peut prêter à confusion. En C+ + 1 1, les enum non délimités peuvent également 
faire l’objet d’une déclaration anticipée, mais sous condition d’un petit travail 
supplémentaire. Il s’agit d’exploiter le fait que chaque enum C++ possède un type 
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entier sous-jacent déterminé par le compilateur. Prenons l’exemple de l’énumération 

Col or : 

enum Color ( black, white, red I; 

Le compilateur peut choisir char comme type sous-jacent, car il n’a que trois valeurs 
à représenter. En revanche, certains enum affichent une plage de valeurs beaucoup plus 
vaste : 


enum Status 1 good = 0, 
fai 1 ed = 1, 
incomplète = 100, 
corrupt = 200, 
indeterminate = OxFFFFFFFF 


Dans ce cas, les valeurs à représenter vont de 0 à OxFFFFFFFF. Sur une machine 
classique (certains systèmes spécifiques représentent un char avec au moins 32 bits), 
le compilateur devra choisir un type entier plus grand qu’un char pour représenter les 
valeurs de Status. 

Afin d’optimiser l’utilisation de la mémoire, le compilateur choisit souvent pour 
représenter un enum le plus petit type sous-jacent capable d’accepter l’étendue des 
valeurs de l’énumérateur. Le compilateur pourra également décider d’optimiser la 
vitesse plutôt que la taille et, dans ce cas, ne choisira pas le type sous-jacent le plus 
petit possible, tout en gardant une taille raisonnable. Pour que cela soit possible, 
C++98 accepte uniquement les définitions d’enum (tous les énumérateurs doivent être 
indiqués) ; les déclarations d’enum ne sont pas autorisées. Le compilateur est ainsi 
capable de sélectionner le type sous-jacent de chaque enum avant que l’énumération 
ne soit utilisée. 

Mais l’incapacité à déclarer de façon anticipée des enum présente des inconvénients. 
Le principal étant probablement l’augmentation des dépendances de compilation. 
Reprenons l’énumération Status : 

enum Status I good = 0, 
fai 1 ed = 1, 
incomplète = 100, 
corrupt = 200, 
indeterminate = OxFFFFFFFF 

1; 

Il est fort probable qu’un tel enum sera utilisé dans de nombreux endroits d’un 
système et qu’il sera donc inclus dans un fichier d’en-tête dont dépendra chaque partie 
de ce système. Supposons qu’une nouvelle valeur d’état soit ajoutée : 

I enum Status 1 good = 0, 
fai 1 ed = 1, 
incomplète = 100, 
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corrupt = 200, 
audited = 500, 
indeterminate = OxFFFFFFFF 


Cette modification imposera certainement une nouvelle compilation de l’intégra- 
lité du système, même si un seul sous-système, voire une seule fonction, se sert de 
l’énumérateur ajouté. C’est vraiment le genre de choses que les développeurs haïssent. 
Et c’est le genre de choses que les déclarations anticipées d’en uni en C+ + 1 1 permettent 
d’éviter. Par exemple, voici une déclaration parfaitement valide d’une énumération 
délimitée et d’une fonction qui l’attend en paramètre : 


I enum class Status; // Déclaration anticipée. 

void continueProcessing(Status s); // Utiliser l’enum déclaré en amont. 

L’en-tête qui contient ces déclarations n’a pas besoin d’être recompilé lorsque la 
définition de Status évolue. Par ailleurs, si Status est modifié (par exemple pour ajouter 
l’énumérateur audited) et si le comportement de conti nueProcessi ng n’en est pas 
affecté (par exemple parce que conti nueProcessi ng n’utilise pas audited), il n’est pas 
utile de recompiler son implémentation. 

Mais, si le compilateur a besoin de connaître la taille d’un enum avant que 
l’énumération puisse être utilisée, comment peut-il s’en sortir avec les enum C++11 
déclarés en amont alors qu’il n’y parvient pas avec les enum C++98. La réponse est 
simple : le type sous-jacent d’une énumération délimitée est toujours connu et, pour 
une énumération non délimitée, nous pouvons le préciser. 

Pour les enum délimités, le type sous-jacent par défaut est i n t : 

enum class Status; // Le type sous-jacent est int. 

Si le type par défaut ne convient pas, nous pouvons le changer : 


I enum class Status: std: :uint32_t; // Le type sous-jacent pour 

// Status est std: :uint32_t 
// (extrait de <cstdint>). 

Pour une énumération délimitée, le compilateur connaît donc toujours la taille 
des énumérateurs. 

Dans le cas d’une énumération non délimitée, nous pouvons préciser le type 
sous-jacent de la même manière et le résultat peut faire l’objet d’une déclaration 
anticipée : 


enum Color: std: :uint8_t; 


// Déclaration anticipée d’un enum 
// non délimité ; le type sous-jacent 
// est std: :uint8_t 



Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 10. Préférer les enum délimités aux enum non délimités 



La spécification du type sous-jacent peut également se faire sur une définition 
d’enum : 


enum class Status: std: : u i n 1 3 2_t I good = 0, 

failed = 1, 
incomplète = 100, 
corrupt = 200, 
audited = 500, 
indeterminate = OxFFFFFFFF 


Étant donné que les enum délimités évitent la pollution de l’espace de noms et 
qu’ils ne sont pas sujets aux conversions de type implicites ineptes, vous risquez d’être 
surpris d’apprendre qu’il existe au moins un cas où les enum non délimités présentent un 
intérêt : dans les références à des champs dans des std::tuplede C+ + 1 1. Supposons 
par exemple que nous ayons un tuple qui contient des valeurs représentant le nom, 
l’adresse électronique et la renommée d’un utilisateur sur un site de réseau social : 


using Userlnfo = 
std: : tupi e<std : :string, 
std: :string, 
std: :size_t>; 


// Alias de type (voir le conseil 9) 
// nom 

// adresse électronique 
// renommée 


Même si les commentaires expliquent ce que chaque champ du tuple représente, 
ces informations ne seront probablement pas très utiles lors de la lecture d’un code 
qui se trouve dans un fichier source distinct : 


Userlnfo ulnfo; 


// Objet du type du tuple. 


T3 

n 
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auto val = std: :get<l>(u Info ) : // Obtenir la valeur du champ 1. 

En tant que programmeurs, nous avons de nombreux aspects à suivre. Comment 
pouvons-nous nous rappeler que le champ 1 correspond à l’adresse électronique de 
l’utilisateur ? La solution passe par une énumération non délimitée de façon à associer 
des noms aux numéros des champs : 

enum UserlnfoFields { uiName, uiEmail, uiReputation }; 

Userlnfo ulnfo; // Comme précédemment. 


auto val = std: :get<ui Emai IXulnfo) ; // Obtenir la valeur du champ de 

// l’adresse électronique. 

Cela fonctionne en raison de la conversion implicite de UserlnfoFields en 
std ; : si ze_t, précisément le type demandé par std : : get. 

Le code équivalent avec des énumérations délimitées est un tantinet plus verbeux : 
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enum class UserlnfoFields I uiName, ui Email, uiReputation ); 
Userlnfo ulnfo; Il Comme précédemment. 


auto val = 

std: :get<static_cast<std: : si ze_t>( UserlnfoFields : :ui Email )> 

(ulnfo) ; 

Il est possible de faire plus court en écrivant une fonction qui prend en paramètre 
un énumérateur et qui retourne la valeur std : : si ze_t correspondante, mais la solution 
est un peu tirée par les cheveux, std: :get est un template et la valeur que nous 
fournissons est un argument de template (notez l’utilisation de crochets obliques, non 
de parenthèses). Par conséquent, la fonction qui transforme un énumérateur en un 
std: :size_t doit générer son résultat pendant la compilation. Comme l’explique le 
conseil 15, elle doit donc être une fonction constexpr. 

En réalité, elle doit être un template de fonction constexpr car elle doit opérer 
avec n’importe quel enum. Et si nous devons effectuer cette généralisation, elle doit 
aussi concerner le type de retour. Au lieu de renvoyer std : : si ze_t, nous retournons le 
type sous-jacent de l’en uni. Il est disponible via les traits de type std : : underlyi ng_type 
(voir le conseil 9 pour de plus amples informations sur les traits de type). Enfin, nous 
la déclarons noexcept (voir le conseil 14), car nous savons qu’elle ne lancera jamais 
d’exception. Nous obtenons un template de fonction toUType qui prend en argument 
un énumérateur quelconque et retourne sa valeur au moment de la compilation : 


templ ate<typename E> 

constexpr typename std: :underlying_type<E>: :type 
toUType(E enumerator) noexcept 


return 

stati c_cast<typename 

std: :underlying_type<E>: :type>(enumerator) ; 


En C++ 14, il est possible de simplifier toUType en remplaçant typename 
std: : underlyi ng_type<E>: :type par l’écriture plus courte std: : underlyi ng_type_t 
(voir le conseil 9) : 


templ ate<typename E> // C++14. 

constexpr std: : underlyi ng_type_t<E> 
toUType(E enumerator) noexcept 

1 

return static_cast<std: :underlying_type_t<E»(enumerator) : 


Le type de retour, encore plus court, auto (voir le conseil 3) est également valide 
en C+ + 14 : 
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templ ateCtypename E> Il C++14. 

constexpr auto 

toUType(E enumerator) noexcept 

( 

return static_cast<std: :underlying_type_t<E»( enumerator) ; 


Quelle que soit la manière de le décrire, toUType nous permet d’accéder à un champ 
du tuple de la manière suivante : 

auto val = std: :get<toUType(UserInfoFields: : ui Ema i 1 )XuInfo) ; 

Si cela reste encore plus long qu’avec une énumération non délimitée, nous évitons 
la pollution de l’espace de noms et les conversions accidentelles sur les énumérateurs. 
Dans de nombreux cas, la saisie de quelques caractères supplémentaires est un prix 
raisonnable à payer pour éviter les pièges associés à une technologie d’énumération 
qui date de l’époque où le modem à 2 400 bauds représentait l’état de l’art des 
télécommunications numériques. 


À retenir 

• Les en uni de style C++98 sont appelés énumérations non délimitées. 

• Dans les énumérations délimitées, les énumérateurs sont visibles uniquement à 
l'intérieur de l'en uni. Ils sont convertis dans d'autres types uniquement par des 
conversions explicites. 

• Les énumérations délimitées ou non acceptent la spécification du type sous-jacent. 
Pour les enum délimités, le type sous-jacent par défaut est int. Les enum non 
délimités n'ont pas de type sous-jacent par défaut. 

• Il est toujours possible de déclarer de façon anticipée des énumérations 
délimitées. Cela reste possible avec les énumérations non délimitées, mais 
le type sous-jacent doit être précisé. 


CONSEIL N il. PRÉFÉRER LES FONCTIONS 
SUPPRIMÉES AUX FONCTIONS INDÉFINIES PRIVÉES 


© 


Si nous fournissons du code à d’autres développeurs et souhaitons les empêcher 
d’appeler une fonction précise, il suffit de ne pas déclarer cette fonction. Sans fonction 
déclarée, il ne peut pas y avoir de fonction à appeler. Facile comme tout. Mais il arrive 
que C++ déclare des fonctions à notre place et si nous voulons éviter que les clients 
n’appellent ces fonctions, ce n’est plus du tout aussi simple. 

Ce cas se produit uniquement pour les « fonctions membres spéciales », c’est-à-dire 
les fonctions membres générées automatiquement par C++ lorsqu’elles sont requises. 
Le conseil 17 détaille ces fonctions mais, pour le moment, nous allons nous intéresser 
uniquement au constructeur de copie et à l’opérateur d’affectation par copie. Ce 
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chapitre est largement consacré aux pratiques courantes en C++98 remplacées par de 
meilleures pratiques en C++1 1. Et, en C++98, lorsque l’on souhaite supprimer l’usage 
d’une fonction, il s’agit presque toujours du constructeur de copie, de l’opérateur 
d’affectation, ou des deux. 

En C++98, la solution consiste à déclarer ces fonctions private et à ne pas les 
définir. Par exemple, près du début de la hiérarchie des iostream dans la bibliothèque 
standard de C++, nous trouvons le template de classe basic_ios. Toutes les classes 
d’istream et d’ostream dérivent, parfois indirectement, de celle-ci. La copie d’istream 
et d’ostream n’est pas souhaitable car le fonctionnement de telles opérations n’est 
pas parfaitement clair. Par exemple, un objet i stream représente un flux de valeurs 
d’entrée, dont certaines peuvent déjà avoir été lues, d’autres l’étant potentiellement 
plus tard. Si un istream devait être copié, faudrait-il copier toutes les valeurs qui ont 
déjà été lues ainsi que celles qui seront lues par la suite ? La manière la plus simple de 
répondre à ces questions est de les faire disparaître. C’est précisément ce qui se passe 
en interdisant la copie des flux. 

Pour que les classes d’istream et d’ostream ne puissent pas être copiées, basi c_i os 
est spécifié de la manière suivante en C++98 (commentaires compris) : 

template <class charT, class traits = char_traits<charT> > 
class basic_ios : public iosjbase { 
publ ic: 


private: 

basic_ios(const basi c_i os& ); // not defined 

basic_ios& operator=(const basic_ios&); // not defined 


Puisque ces fonctions sont déclarées pri vate, elles ne peuvent pas être appelées 
depuis du code client. Si du code a néanmoins accès à ces fonctions (fonctions 
membres ou classes fri end) et les utilise, l’édition de liens échouera car elles ne 
sont pas définies. 

En C++1 1, il existe une meilleure manière d’obtenir les mêmes résultats : faire du 
constructeur de copie et de l’opérateur d’affectation par copie des fonctions supprimées 
en les marquant avec « = del ete ». Voici la même partie de basi c_i os, cette fois-ci 
dans sa version C++ 1 1 : 

template <class charT, class traits = char_traits<charT> > 

class basi c_i os : public iosjbase I 

public: 

basic_ios(const basic_ios& ) = delete; 
basic_ios& operator=(const bas i c_i os& ) = delete; 


On pourrait croire que la différence entre supprimer ces fonctions et les déclarer 
private n’est qu’une question de mode, mais elle est en réalité beaucoup plus profonde. 
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Les fonctions supprimées ne peuvent pas être utilisées de quelque façon que ce soit, 
et même le code présent dans des fonctions membres ou fri end ne compilera pas s’il 
tente de copier des objets basi c_i os. Voilà une amélioration par rapport à C++98, où 
une telle utilisation impropre ne serait découverte qu’à l’édition de liens. 

Par convention, les fonctions supprimées sont déclarées non pas priva te mais 
public. En effet, lorsque du code client tente d’utiliser une fonction membre, C+ + 
vérifie l’accessibilité avant l’état supprimé. Si un code client tente d’utiliser une 
fonction supprimée private, certains compilateurs indiqueront uniquement qu’elle 
est privée, même si son accessibilité est en réalité sans rapport avec la possibilité de 
l’utiliser. Il est préférable de tenir compte de ce point lorsque du code ancien est revu 
de façon à remplacer les fonctions membres private non définies par des fonctions 
supprimées. En déclarant ces nouvelles fonctions publ i c, les messages d’erreurs seront 
généralement plus précis. 

Les fonctions supprimées ont également un autre avantage important : n’importe 
quelle fonction peut être supprimée, tandis que seules les fonctions membres peuvent 
être p ri vate. Par exemple, supposons que nous ayons une fonction non membre qui 
prend un entier et renvoie un chiffre porte-bonheur : 

bool i s Lucky ( i nt number); 

Les origines C du C++ font que pratiquement n’importe quel type peut être 
considéré comme plus ou moins numérique, avec une conversion implicite en i nt. 
Cependant certains appels, qui passent à la compilation, pourraient avoir peu de sens : 

if (isLucky('a')) ... // 'a' est-il un chiffre porte-bonheur ? 

if (i sLucky(true) ) ... // Et "true” ? 

if (i s Lucky (3.5) ) ... // Faut-il tronquer à 3 avant de 

// vérifier si on est chanceux ? 

Si les chiffres porte-bonheur doivent réellement être des entiers, il faut que ces 
appels ne puissent pas être compilés. 

Une solution consiste à créer des surcharges supprimées pour les types à écarter : 

bool i s Lucky ( i nt number); // Fonction d’origine. 

bool isLucky(char) = delete; // Rejeter les caractères. 

bool i s Lucky ( bool ) = delete; // Rejeter les booléens. 

bool isLucky(double) = delete; // Rejeter les double et les float. 

Le commentaire sur la surcharge avec double indique que les doubl e et les f 1 oat 
seront écartés. Cela pourrait vous surprendre, mais n’oubliez pas que, lorsqu’un fl oat 
peut être converti en i nt ou en doubl e, C++ choisit la conversion vers un doubl e. En 
appelant i s Lucky avec un fl oat, la surcharge pour un doubl e, non celle pour un i nt, 
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est appelée. En réalité, elle ne sera pas appelée car elle est supprimée, ce qui interdit 
la compilation de l’appel. 

Même si les fonctions supprimées ne peuvent pas être utilisées, elles font partie 
du programme. Elles sont donc prises en compte lors de la résolution de la surcharge. 
C’est pourquoi, avec les déclarations de fonctions supprimées précédentes, les appels 
indésirables à i sLucky seront rejetés : 


if (isLucky('a')) ... 
if (isLucky(true)) ... 
if ( isLucky(3. 5f ) ) ... 


// Erreur ! Appel à une fonction supprimée. 
// Erreur ! 

// Erreur ! 


De plus, les fonctions supprimées, contrairement aux fonctions membres pri vate, 
permettent d’empêcher l’instanciation de template. Par exemple, supposons que nous 
ayons besoin d’un template qui manipule des pointeurs intégrés (le chapitre 4 conseille 
d’adopter les pointeurs intelligents plutôt que les pointeurs bruts) : 


| template<typename T> 

voici processPointerCT* ptr); 

Dans le monde des pointeurs, il existe deux cas particuliers. Le premier concerne 
les pointeurs voi d*, car il n’existe aucun moyen de les déréférencer, de les incrémenter 
ou de les décrémenter, etc. Le second concerne les pointeurs char*, car ils représentent 
souvent des pointeurs sur des chaînes de caractères de type C, non des pointeurs sur des 
caractères individuels. Ces cas spéciaux nécessitent souvent un traitement particulier 
et, dans le cas du template processPoi nter, nous supposons que l’objectif est de rejeter 
les appels qui utilisent ces types. Autrement dit, il faut que les appels à processPoi nter 
avec des pointeurs voi d* ou char*ne soient pas autorisés. 

Pour cela, il suffit de marquer les instanciations suivantes par del ete : 


templateO 

void processPointer<void>(void*) = delete; 
templ ate<> 

void processPointer<char>(char*) = delete; 

Si un appel à processPoi nter avec un void* ou un char* est désormais invalide, 
il est probable qu’un appel avec un const void* ou un const char* devrait l’être 
également. Par conséquent, ces instanciations doivent elles aussi être supprimées : 


templ ate<> 

void processPointer<const voidXconst void*) = delete; 


templ ate<> 

void processPointer<const charXconst char*) = delete; 
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Pour être véritablement rigoureux, nous devons également supprimer les surcharges 
avec const volatile void* et const volatile char*, puis travailler sur celles avec 
des pointeurs des autres types de caractère standard : std : :wchar_t, std : : charl6_t et 
std: :char32_t. 

Si nous avons un template de fonction dans une classe et si nous souhaitons 
interdire certaines instanciations en les déclarant pri va te (à la manière classique de 
C++98), ce n’est tout simplement pas possible. En effet, on ne peut pas donner à une 
spécialisation de template de fonction membre un niveau d’accès différent de celui 
du template principal. Supposons, par exemple, que processPointer soit un template 
de fonction membre dans Widget et que nous voulions interdire les appels avec des 
pointeurs voi d*. Même si elle ne compilera pas, voici l’approche C++98 : 

publ i c : 

templ ate<typename T> 

void processPointer(T* ptr) 

I ... I 

private: 

templateO // Erreur ! 

void processPointer<voidXvoid*) ; 
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Le problème vient du fait que les spécialisations de template doivent être écrites 
non pas dans une portée de classe mais dans la portée de l’espace de noms. Ce problème 
n’existe pas avec les fonctions supprimées, car elles n’ont pas besoin d’un niveau 
d’accès différent. Elles peuvent être supprimées en dehors de la classe (donc dans la 
portée de l’espace de noms) : 

class Widget I 
publ i c : 

templ ate<typename T> 
void processPointertT* ptr) 

I ... I 


I templateO // Toujours publique, 

void Widget: :processPointer<void>(void*) = delete; // mais supprimée. 

En vérité, la déclaration de fonctions private sans les définir était la tentative 
C++98 d’obtenir ce que les fonctions supprimées permettent d’accomplir en C++ 1 1 . 
L’approche de C++98 n’est pas aussi bonne. Elle ne fonctionne pas en dehors 
des classes, elle ne fonctionne pas toujours à l’intérieur des classes et, lorsqu’elle 
fonctionne, ce n’est souvent qu’au moment de l’édition de liens. Il est donc préférable 
de s’en tenir aux fonctions supprimées. 
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À retenir 

• Les fonctions supprimées doivent être préférées aux fonctions privées non 
définies. 

• N'importe quelle fonction peut être supprimée, y compris les fonctions non 
membres et les instanciations de template. 


CONSEIL N° 1 Z. DÉCLARER LES FONCTIONS 
DE SUBSTITUTION AVEC OVERRIDE 


En C++, le monde de la programmation orientée objet tourne autour des classes, de 
l’héritage et des fonctions virtuelles. L’une des idées fondamentales qui régissent ce 
monde est que les implémentations des fonctions virtuelles dans des classes dérivées 
redéfinissent les implémentations de leurs homologues dans la classe de base. Il est donc 
assez décourageant de réaliser à quel point la redéfinition d’une fonction virtuelle peut 
aisément mal se passer. C’est un peu comme si cette partie du langage était conçue 
avec l’idée qu’on ne devait pas respecter la loi de Murphy, simplement l’honorer. 

Puisque « redéfinition » sonne beaucoup comme « surcharge », rappelons claire- 
ment que c’est grâce à la redéfinition d’une fonction virtuelle que nous pouvons 
invoquer une fonction d’une classe dérivée au travers d’une interface de la classe de 
base : 


class Base I 
publ ic: 

Virtual void doWorkO; // Fonction virtuelle de la classe de base. 


class Derived: public Base { 
publ ic: 

Virtual void doWorkO; 


1; 


// Redéfinition de Base::doWork 
// ("Virtual" est facultatif dans 
// ce cas). 


std: :unique_ptr<Base> upb = 
std: :make_unique<Derived>( ) ; 


// Créer un pointeur de la classe de base 
// vers un objet de la classe dérivée ; 

// voir le conseil 21 pour des infos 
// sur std: :make_unique. 


upb->doWork( ) ; 


// Appeler doWork via le pointeur ptr 
Il de la classe de base ; la fonction 
Il de la classe dérivée est invoquée. 


La mise en place de la redéfinition requiert plusieurs conditions : 
• La fonction de la classe de base doit être virtuelle. 
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• Les noms de la fonction dans la classe de base et dans la classe dérivée doivent 
être identiques (excepté dans le cas des destructeurs). 

• Les types des paramètres de la fonction dans la classe de base et dans la classe 
dérivée doivent être identiques. 

• Les caractères const de la fonction dans la classe de base et dans la classe dérivée 
doivent correspondre. 

• Les types de retour et les spécifications des exceptions de la fonction dans la 
classe de base et dans la classe dérivée doivent être compatibles. 

À ces contraintes, qui font partie de C++98, C+ + 1 1 en ajoute une autre : 

• Les qualificatifs de référence des fonctions doivent être identiques. Les qualificatifs 
de référence sur les fonctions membres sont parmi les fonctionnalités les moins 
connues de C++ 1 1 ; ne soyez pas surpris si vous n’en avez jamais entendu parler. 
Ils permettent de restreindre l’utilisation d’une fonction membre uniquement 
aux lvalues ou aux rvalues. Les fonctions membres n’ont pas besoin d’être 
virtuelles pour les utiliser : 


-o 

n 


© 


ciass Widget i 
publ i c : 

Il Cette version de doWork est utilisée 
Il uniquement lorsque *this est une lvalue. 

Il Cette version de doWork est utilisée 
Il uniquement lorsque *this est une rvalue. 


Il Fonction fabrique (retourne une rvalue). 
Il Objet normal (une lvalue). 


Il Appeler Widget: rdoWork pour les lvalues 
Il (c’est-à-dire Widget: :doWork &). 

Il Appeler Widget: :doWork pour les rvalues 
Il (c’est-à-dire Widget: :doWork &&). 

Nous reviendrons ultérieurement sur les fonctions avec des qualificatifs de réfé- 
rence mais, pour le moment, notez simplement que si une fonction virtuelle dans 
une classe de base est marquée d’un qualificatif de référence, la redéfinition de cette 
fonction dans la classe dérivée doit comprendre exactement le même qualificatif 
de référence. Dans le cas contraire, les fonctions déclarées existeront dans la classe 
dérivée, mais elles ne redéfiniront pas celles de la classe de base. 

Toutes ces exigences sur la redéfinition signifient que de petites erreurs peuvent 
faire une grande différence. En général, le code qui contient des erreurs de redéfinition 
ne posera pas de problème de compilation, mais il n’aura pas le fonctionnement 


void doWorkO &; 

void doWorkO &&; 

1: 

Widget makeWidgetO ; 
Widget w; 

w.doWork( ) ; 

makeWi dget ( ) ,doWork( ) ; 
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attendu. Nous ne pouvons donc pas compter sur le compilateur pour nous prévenir. Par 
exemple, le code suivant est parfaitement valide et, à première vue, semble raisonnable, 
mais il ne contient aucune redéfinition de fonction virtuelle - aucune fonction de 
classe dérivée n’est liée à une fonction de la classe de base. Pouvez-vous identifier le 
problème de chaque cas, c'est-à-dire indiquer pourquoi chaque fonction de la classe 
dérivée ne redéfinit pas la fonction de même nom dans la classe de base ? 


class Base { 
publ ic: 

vi rtual void mf 1 ( ) const; 
Virtual void mf 2 ( i nt x ) ; 
Virtual void mf 3 ( ) &; 
void mf4( ) const; 


class Derived: publ 
publ ic: 

Virtual void mf 1 ( 
Virtual void mf 2 ( 
Virtual void mf 3 ( 
void mf 4 ( ) const; 


ic Base { 

); 

unsigned i nt x); 
) &&; 


Voici un peu d’aide : 

• mf 1 est déclarée const dans Base, mais pas dans Deri ved. 

• mf 2 prend un paramètre de type i nt dans Base, mais de type unsigned int dans 
Deri ved. 

• mf3 a un qualificatif de lvalue dans Base, mais de rvalue dans Deri ved. 

• mf4 n’est pas déclarée vi rtual dans Base. 

Vous pourriez penser que, dans la pratique, tous ces points conduiront à des 
avertissements du compilateur et que vous n’avez donc pas à vous en inquiéter. C’est 
peut-être vrai, mais pas certain. Deux des compilateurs que nous avons testés ont 
accepté le code sans broncher, alors même que le niveau d’avertissement était à son 
maximum. (D’autres compilateurs ont affiché des avertissements uniquement pour 
certains problèmes.) 

Puisque la déclaration des redéfinitions dans une classe dérivée est importante 
pour que le code fonctionne correctement, mais qu’il est facile de se tromper, C+ + 1 1 
apporte une solution pour indiquer explicitement qu’une fonction d’une classe dérivée 
est supposée redéfinir une version de la classe de base : il suffit de la déclarer avec 
o ver ri de. Appliquons cette solution à l’exemple précédent : 


class Derived: 
publ ic: 

Virtual void 
Virtual void 
Virtual void 
Virtual void 


public Base { 

mfl() override; 
mf2(unsigned int x) override; 
mf 3 ( ) && override; 
mf 4 ( ) const override; 
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Ce code ne compilera pas car, écrit de cette manière, le compilateur se plaindra de 
problèmes associés à la redéfinition. C’est précisément ce que nous souhaitons et c’est 
pourquoi il faut déclarer toutes les fonctions de substitution avec overri de. 

Voici la version valide du code fondé sur overri de (en supposant que l’objectif soit 
que toutes les fonctions de Deri ved redéfinissent les fonctions virtuelles de Base) : 

class Base I 
publ i c : 

vi rtual void mf 1 ( ) const; 
vi rtual void mf 2 ( i nt x) ; 
vi rtual void mf3( ) &; 

Virtual void mf 4 ( ) const; 

1 ; 

class Derived: public Base ( 
public: 

Virtual void mfl() const override; 

Virtual void mf2(int x) override; 

Virtual void mf3() & override; 

void mf 4 ( ) const override; // Ajouter "Virtual" est facultatif. 

Vous aurez noté que, dans cet exemple, déclarer mf4 virtuelle dans Base fait partie 
des corrections. En général, les problèmes de redéfinition proviennent des classes 
dérivées, mais il est également possible que les erreurs se trouvent dans les classes de 
base. 

En appliquant override à toutes les redéfinitions dans une classe dérivée, nous 
obtenons bien plus que des messages du compilateur en cas de problème. En effet, cela 
nous aide à mesurer les ramifications d’un changement de la signature d’une fonction 
virtuelle dans une classe de base. Si les classes dérivées emploient systématiquement 
override, nous pouvons simplement modifier la signature, recompiler l’ensemble et 
constater les dommages que nous pouvons avoir causés (c’est-à-dire le nombre de 
classes dérivées qui ne compilent plus). Ensuite, il ne reste plus qu’à décider si la 
modification de la signature en vaut la peine. Sans override, nous devrions nous 
reposer sur l’exhaustivité des tests unitaires car, nous l’avons vu, le compilateur ne 
nous préviendra pas si des fonctions virtuelles d’une classe dérivée ne redéfinissent pas 
des fonctions de la classe de base alors que nous le supposons. 

Les mots clés existent depuis toujours en C+ + , mais C+ + 1 1 ajoute deux mots clés 
contextuels, override et final 1 . Ces mots clés ont une signification réservée, mais 

1. Appliquer final à une fonction virtuelle empêche la redéfinition de cette fonction dans les classes 
dérivées, fi nal peut également être appliqué à une classe, auquel cas celle-ci ne pourra pas servir de 
© classe de base. 
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uniquement dans certains contextes. Ainsi, override ne prend son sens réservé que 
s’il se trouve à la fin de la déclaration d’une fonction membre. Autrement dit, si du 
code ancien utilise déjà le nom override, il est inutile de le modifier pour le rendre 
compatible avec C++ 1 1 : 

class Warning ( // Ancienne classe de C++98. 

publ ic: 

void override! ); // Valide en C++98 et en C++11 

// (avec le même sens) . 


Nous en avons fini avec override, mais ce n’est pas le cas des qualificatifs de 
référence sur les fonctions membres. Voici le complément d’information que nous 
avions promis. 

Si nous souhaitons écrire une fonction qui accepte uniquement des arguments 
Ivalue, nous déclarons un paramètre de référence Ivalue non const : 

void doSomething(Widget& w); // Accepter uniquement des Widget Ivalue. 

Pour écrire une fonction qui accepte uniquement des arguments rvalue, nous 
déclarons un paramètre de référence rvalue : 

void doSomething(Widget&& w); // Accepter uniquement des Widget rvalue. 

Grâce aux qualificatifs de référence sur les fonctions membres, nous pouvons 
appliquer la même distinction sur l’objet sur lequel une fonction membre est invoquée, 
c’est-à-dire sur *this. On pourrait comparer cela au const placé à la fin de la 
déclaration d’une fonction membre pour indiquer que l’objet sur lequel la fonction 
membre est invoquée (c’est-à-dire *thi s) est const. 

Les fonctions membres avec des qualificatifs de référence sont rarement nécessaires, 
mais cela arrive. Par exemple, supposons que notre classe Widget comprenne une 
donnée membre std: :ve ctor et que nous proposions une méthode accesseur qui 
donne au code client un accès direct à cette donnée : 


class Widget I 

public: 

using DataType = std: :vector<double>; // Voir le conseil 9 pour 

// des infos sur "using". 


DataTypeS dataO I return values; I 


pri vate: 

DataType values; 
I; 
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On peut difficilement dire que cette encapsulation soit parfaite, mais mettons cela 
de côté et voyons ce qui se passe dans le code client suivant : 

Widget w ; 

auto valsl = w. datai); Il Copier w. values dans va 1 s 1 . 

Le type de la valeur de retour de Widget: :data est une référence lvalue (plus 
précisément std: : vectoKdoubl e>&) et puisque ces références sont définies comme 
des Ivalues, nous initialisons valsl à partir d’une lvalue. Par conséquent, valsl est 
construit par copie à partir de w. val ues, comme l’indique le commentaire. 

Supposons à présent que nous ayons une fonction fabrique qui crée des Widget : 

Widget makeWidgeti ) ; 

Et que nous souhaitions initialiser une variable avec le std : : vector qui se trouve 
à l’intérieur du Widget renvoyé par makeWidget : 

auto va 1 s2 = makeWidgeti ) .datai ) ; // Copier dans val s2 les values 

// présents dans le Widget. 

Widget:: data retourne à nouveau une référence lvalue et, à nouveau, cette 
référence est une lvalue. Par conséquent, notre nouvel objet (vals2) est encore 
construit par copie à partir du values qui se trouve dans le Widget. Toutefois, le 
Widget est cette fois-ci l’objet temporaire renvoyé par makeWidget (c’est-à-dire une 
rvalue) et la copie du std : : vector qu’il contient constitue une perte de temps. Il serait 
préférable de le déplacer car data retourne une référence lvalue et les règles du C+ + 
exigent que le compilateur génère du code pour une copie. (Il serait possible de mettre 
en place une optimisation au travers de ce que l’on appelle la règle « as if », mais il 
serait stupide de se fonder sur le compilateur pour trouver une façon d’en tirer parti.) 

Ce dont nous avons besoin, c’est une manière de préciser que l’invocation de 
data sur un Widget rvalue doit produire une rvalue. Nous l’avons, en utilisant les 
qualificatifs de référence pour surcharger data selon que le Widget est une lvalue ou 
une rvalue : 

class Widget 1 

publ ic: 

using DataType = std: :vector<double>; 

DataType& datai ) & // Pour les Widget lvalue, 

I return values; 1 // retourner une lvalue. 

DataType datai) && // Pour les Widget rvalue, 

I return std: :move(val ues) ; 1 // retourner une rvalue. 
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p r i v a t e : 

DataType values; 

1; 


Notez la différence dans les types de retour de surcharge de data. La surcharge pour 
les références lvalue renvoie une référence lvalue (c’est-à-dire une lvalue), tandis que 
la surcharge pour les références rvalue renvoie un objet temporaire (c’est-à-dire une 
rvalue). Le code client se comporte à présent comme nous le souhaitons : 


auto valsl = w. datai ) ; 


// Appelle la surcharge lvalue de 
// Widget: :data, construit valsl 
// par copie. 


auto val s2 = makeWidget( ) .datai ) ; 


Il Appelle la surcharge rvalue de 
Il Widget: :data , construit va 1 s 2 
Il par dépi dcement. 


Tout cela est très bien, mais ne laissons pas cette fin heureuse nous distraire du 
véritable sujet de ce conseil : dès lors que nous déclarons dans une classe dérivée une 
fonction qui doit redéfinir une fonction virtuelle de la classe de base, nous devons la 
déclarer avec override. 


À retenir 

• Les fonctions de substitution doivent être déclarées avec override. 

• Les qualificatifs de référence sur les fonctions membres permettent de traiter les 
objets lvalue et rvalue (*thi s) de façon différente. 


CONSEIL N° 13. PRÉFÉRER LES C0NST_ITERAT0R 
AUX ITERATOR 

Les const_i terator sont les équivalents STL des pointeurs sur const. Ils pointent sur 
des valeurs qui ne peuvent pas être modifiées. La bonne pratique qui veut que const 
soit utilisé dès que c’est possible engage à utiliser les const_i terator chaque fois qu’un 
itérateur est requis et que les éléments ciblés par cet itérateur n’ont pas besoin d’être 
modifiés. 

C’est vrai en C++98 comme en C+ + 1 1, mais, en C++98, la prise en charge des 
const_i terator était médiocre. Il n’était pas facile de les créer et, une fois cela fait, 
les façons de les utiliser étaient limitées. Par exemple, supposons que nous voulions 
rechercher dans un std: ; vector<int> la première occurrence de 1983 (l’année où 
« C++ » est devenu le nom du langage de programmation à la place de « C avec des 
classes »), puis insérer la valeur 1998 (l’année où la première norme ISO du C++ a 
été adoptée) à cet emplacement. Si le vecteur ne contient pas 1983, l’insertion doit 
se faire à la fin du vecteur. Avec les i terator de C++98, la solution est simple : 
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std: : vector<int> values; 


I std: :vector<int>: :iterator it = 

std: : find(val ues.begi n( ) , val ues . end ( ) , 1983) ; 
values. i nsert ( i t , 1998); 

Cependant, les iterator ne sont pas vraiment adaptés dans ce cas, car ce code 
ne modifie jamais l’élément pointé. La modification du code de façon à utiliser des 
const_i terator devrait être immédiate, mais ce n’est absolument pas le cas en C++98. 
Voici une approche conceptuellement appropriée, mais non valide : 

typedef std; :vector<int>: : iterator IterT; // Définitions des 

typedef std: :vector<int>: :const_iterator ConstlterT; // types. 

std: :vector<int> values; 


ConstlterT ci = 

std: :find(static_cast<ConstIterT>(val ues.begin( )) , // Conversions 

static_cast<ConstIterT>( val ues .end( ) ) , // des types. 

1983); 

values. insert(static_cast<IterTXci ) , 1998); // Peut ne pas compiler ; 

// voir ci -après. 

Bien entendu, les typedef ne sont pas obligatoires, mais ils simplifient l’écriture des 
conversions de types. (Vous vous demandez peut-être pourquoi nous utilisons typedef 
au lieu de suivre le conseil 9, qui préconise l’usage des déclarations d’alias. La raison 
en est simple : cet exemple montre du code C++98 et les déclarations d’alias sont une 
nouvelle fonctionnalité de C++1 1.) 

Nous utilisons des conversions de type dans l’appel à std: : fi nd car values est 
un conteneur non const et, en C++98, obtenir un const_i terator à partir d’un 
conteneur non const est compliqué. Elles ne sont pas strictement nécessaires, car il est 
possible d’obtenir des const_i terator par d’autres moyens, comme lier values à une 
variable de type référence à un const, puis utiliser cette variable à la place de val ues 
dans le code. Toutefois, quelle que soit la méthode qui sera mise en place, obtenir des 
const_i terator sur des éléments d’un conteneur non const restera complexe. 

Après avoir obtenu les const_i terator, les choses se corsent car, en C++98, les 
emplacements des insertions (et des suppressions) ne peuvent être précisés que par 
des i terator ; les const_i terator ne sont pas acceptés. C’est pourquoi, dans le code 
précédent, nous convertissons le const_i terator (obtenu à partir de std : : fi nd) en 
un iterator : passer un const_i terator à i nsert ne compilerait pas. 

Pour être honnête, le code montré ne compilera pas car il n’existe aucune 
conversion portable d’un con s t_i terator en un iterator, pas même à l’aide d’un sta- 
ti c_cast. La solution lourde appelée rei nterpret_cast n’y parviendra pas plus. (Il ne 
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s’agit pas d’une limite de C++98, C+ + 1 1 est également concerné. Les const_i terator 
ne peuvent tout simplement pas être convertis en i terator.) Il existe des solutions 
portables pour générer des i terator qui pointent aux mêmes emplacements que des 
const_i terator, mais elles sont complexes, elles ne s’appliquent pas dans tous les cas 
et ne valent pas la peine d’être présentées dans cet ouvrage. Quoi qu’il en soit, nous 
espérons que vous avez à présent compris que les cons t_i terator posaient tellement 
de difficultés en C++98 qu’ils méritaient rarement que l’on s’y intéresse. En fin de 
compte, les développeurs n’utilisent pas const dès que c’est possible, mais lorsque cela 
se révèle pratique et, en C++98, les const_i terator n’étaient pas très pratiques. 

Tout cela a changé en C++1 1 . Les const_i terator sont désormais faciles à obtenir 
et à utiliser. Les fonctions membres cbegin et cend d’un conteneur génèrent des 
const_i terator, même dans le cas d’un conteneur non const, et les fonctions membres 
de STL qui identifient des emplacements avec des itérateurs (comme i nsert et erase) 
se servent de const_i terator. Pour employer les const_i terator de C++11 dans le 
code C++98 original qui utilise des i terator, rien n’est plus simple : 

std: :vector<int> values; // Comme précédemment. 


auto it = // Utiliser cbegin 

std; :find(values.cbegin() .values. cend( ), 1983); // et cend. 

values. insertfit, 1998); 

Ce code emploie maintenant des const_i terator, qui se révèlent pratiques ! 

Il existe un cas où la prise en charge des const_i terator en C++11 atteint ses 
limites : lors de l’écriture d’une bibliothèque aussi générique que possible. Un tel code 
tient compte du fait que certains conteneurs et structures de données de type conteneur 
fournissent begi n et end (ainsi que cbegi n, cend, rbegi n, etc.) sous forme de fonctions 
non membres plutôt que membres. C’est par exemple le cas des tableaux intégrés et 
de certaines bibliothèques tierces dont les interfaces sont constituées uniquement de 
fonctions indépendantes. Un code totalement générique emploie donc des fonctions 
non membres, sans supposer l’existence de versions membres. 

Nous pouvons ainsi généraliser le code sur lequel nous avons travaillé sous forme 
d’un template f i ndAndlnsert : 


templ ate<typename C, typename V> 
void findAndInsert(C& container, 

const V& targetVal , 
const V& i nsertVal ) 


using std: : cbegi n ; 
using std: :cend; 


// Dans container, rechercher 
// la première occurrence de 
// targetVal, puis insérer 
// insertVal à l’emplacement 
// trouvé. 


auto it = std: :find(cbegin(container) , 
cend(container) , 
targetVal ) ; 


// cbegin non membre. 
// cend non membre. 
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conta iner.insert(it, insertVal ) ; 


Cela fonctionne en C+ + 14, mais pas en C+ + 1 1. En raison d’une omission pendant 
la normalisation, C++1 1 a ajouté les fonctions non membres begi n et end, mais cbegi n, 
cend, rbegi n, rend, crbegi n et crend ont été oubliées. C+ + 14 a corrigé le tir. 

Si nous utilisons C+ + 1 1 et voulons obtenir le code le plus générique possible, mais 
si aucune des bibliothèques que nous utilisons ne fournit les templates manquants pour 
les versions non membres de cbegi n et ses amies, nous pouvons proposer facilement 
nos propres implémentations. Par exemple, voici celle d’une fonction cbegi n non 
membre : 


template <class C> 

auto cbegin(const C& container) ->decl type ( s td : : beg i n ( conta i ner) ) 

( 

return std: :begin(container) ; // Voir les explications ci-après. 


-o 

n 


© 


N’êtes-vous pas surpris de constater que la fonction non membre cbegi n n’appelle 
pas la fonction membre cbegi n ? Nous l’avons également été, mais suivons la logique. 
Ce template de cbegi n accepte n’importe quel type d’argument qui représente une 
structure de données de type conteneur, C, et y accède au travers de son paramètre 
container, de type référence sur const. Si C est un type de conteneur classique (par 
exemple un std: : vector<i nt>), container sera une référence à une version const 
de ce conteneur (par exemple un const std: :vector<int>&). L’invocation de la 
fonction non membre begin (fournie par C++11) sur un conteneur const donne 
un const_i terator, et cet itérateur est celui retourné par ce template. Cette manière 
d’implémenter les choses a un avantage : elle fonctionne même avec les conteneurs 
qui offrent une fonction membre begin (qui, pour les conteneurs, est appelée par 
la fonction non membre begi n de C++1 1 ), mais sans proposer de fonction membre 
cbegi n. Nous pouvons ainsi utiliser cette fonction non membre cbegi n avec des 
conteneurs qui reconnaissent uniquement begi n. 

Ce template fonctionne également lorsque C est un type tableau intégré. Dans ce 
cas, container devient une référence à un tableau const. C++1 1 fournit une version 
de la fonction non membre begi n adaptée aux tableaux et retournant un pointeur sur 
le premier élément du tableau. Les éléments d’un tableau const sont de type const, 
et le pointeur que la fonction non membre begi n renvoie pour un tableau const est 
un pointeur sur un const. Ce type de pointeur est en réalité un cons t_i terator pour 
un tableau. (Pour plus de détails sur la spécialisation d’un template pour les tableaux 
intégrés, consulter le conseil 1 qui traite de la déduction de type dans les templates 
qui prennent en paramètres des références sur des tableaux.) 

Revenons à l’essentiel. L’objectif de ce conseil est de vous encourager à utiliser les 
const_i terator dès que vous le pouvez. La motivation de base - employer const dès 
que cela a un sens - date d’avant C++1 1 mais, lors de la manipulation d’itérateurs en 
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C++98, elle n’était pas très facile à mettre en pratique. En C+ + 1 1, ce n’est plus le cas, 
et C+ + 14 va plus loin en terminant le travail que C+ + 1 1 a laissé derrière lui. 

À retenir 

• Préférer les const_iterator aux iterator. 

• Dans un code aussi générique que possible, préférer les versions non membres 
de begin, end, rbegin, etc., aux fonctions membres équivalentes. 


CONSEIL N° 14. DÉCLARER NOEXCEPT LES FONCTIONS 
QUI NE LANCENT PAS D'EXCEPTIONS 

En C++98, les exceptions étaient plutôt difficiles à dompter. Il fallait récapituler les 
types des exceptions qu’une fonction pouvait lancer et, si l’implémentation de cette 
fonction était modifiée, les spécifications d’exceptions devaient également être revues. 
Un tel changement pouvait remettre en question le fonctionnement du code client 
car les différents appels pouvaient dépendre de la spécification initiale des exceptions. 
Le compilateur apportait généralement peu d’aide pour maintenir la cohérence entre 
l’implémentation des fonctions, les spécifications des exceptions et le code client. De 
nombreux programmeurs ont fini par décider que les spécifications d’exceptions en 
C++98 ne valaient pas la peine qu’ils s’y attardent. 

Pendant les réflexions sur C+ + 1 1, un consensus a émergé : l’information véritable- 
ment intéressante est de savoir si une fonction en lance ou non des exceptions. Tout 
blanc ou tout noir : soit une fonction peut lancer une exception, soit il est certain 
qu’elle n’en lancera pas. Cette dichotomie éventuellement/jamais forme le socle des 
spécifications d’exceptions en C+ + 1 1, qui remplacent celles de C++98. (La variante 
C++98 reste prise en charge, mais elle est déclarée obsolète.) En C++11, la version 
non conditionnelle de noexcept est destinée aux fonctions qui ne lanceront jamais 
d’exceptions. 

La décision de déclarer une fonction noexcept se prend lors de la conception de 
l’interface. Pour le code client, il est très important de connaître le comportement 
d’une fonction vis-à-vis des exceptions. Il lui est possible de savoir si une fonction est 
déclarée noexcept et la réponse peut avoir un impact sur son efficacité et sur sa sûreté 
face aux exceptions. Il est donc aussi important de savoir si une fonction est noexcept 
que de savoir si une fonction membre est const. Ne pas déclarer une fonction noexcept 
alors qu’elle est réputée ne pas lancer d’exceptions révèle une spécification médiocre 
de l’interface. 

Il existe un autre avantage à déclarer noexcept les fonctions qui ne produisent 
aucune exception : le compilateur est capable de générer un meilleur code objet. Pour 
en comprendre la raison, nous allons examiner la différence entre les façons C++98 et 
C+ + 1 1 d’indiquer qu’une fonction ne génère pas d’exceptions. Prenons une fonction f 
qui assure aux appelants qu’ils ne recevront jamais d’exceptions. Voici les deux façons 
d’exprimer cette affirmation : 
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0 

I int f(int x) throwO; // f ne lance pas d’exception : variante C++98. 
int f(int x) noexcept; Il f ne lance pas d’exception : variante C++11. 

Si, au moment de l’exécution, une exception sort de f , la spécification d’exception 
de f n’est pas respectée. Dans le contexte de C++98, la pile des appels est déroulée 
jusqu’à l’appelant de f et, après quelques actions qui ne nous intéressent pas, l’exé- 
cution du programme se termine. Dans le contexte de C+ + 11, le comportement à 
l’exécution est légèrement différent : la pile est peut-être déroulée avant que l’exécution 
du programme ne soit terminée. 

La différence entre dérouler systématiquement et éventuellement la pile des appels 
a un impact important sur la génération du code. Avec une fonction noexcept, 
l’optimiseur n’a pas besoin de conserver la pile d’exécution dans un état déroulable, 
ni de s’assurer que les objets qu’elle contient sont détruits dans l’ordre inverse de 
leur construction, juste pour le cas où une exception se propagerait en dehors de 
la fonction. Les fonctions qui utilisent « throw( ) », ainsi que celles dépourvues de 
spécifications d’exceptions, n’autorisent pas une telle souplesse d’optimisation. Voici 
comment nous pouvons résumer la situation : 

TypeRetour fonction ( params ) noexcept; Il Optimisable au maximum. 

TypeRetour fonction ( params ) throwO; Il Peu optimisable. 

TypeRetour fonction (params); Il Peu optimisable. 

Ce bénéfice justifie à lui seul le choix de déclarer les fonctions noexcept dès lors 
que l’on est certain qu’elles ne produisent aucune exception. 

Pour certaines fonctions, le cas est plus complexe. Les opérations de déplacement 
en sont de bons exemples. Supposons que nous ayons une base de code C++98 
qui utilise un std: : vector<Widget>. Des Widget sont ajoutés de temps en temps au 
std: : vector à l’aide de push_back : 

std: :vector<Widget> vw ; 


Widget w; 


vw.push_back(w) ; 


Supposons que ce code fonctionne parfaitement et que nous n’ayons aucun intérêt 
à le modifier pour le convertir en C+ + 11. Pourtant, nous souhaitons tirer parti de 
la sémantique de déplacement de C++ 11 qui peut améliorer les performances du 
code ancien lorsque des types compatibles avec le déplacement sont impliqués. Nous 


// Manipuler w. 

// Ajouter w à vw. 
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nous assurons donc que Widget dispose des opérations de déplacement, que ce soit 
en les écrivant nous-mêmes ou en vérifiant que les conditions de leur génération 
automatique sont remplies (voir le conseil 17). 

Lors de l’ajout d’un nouvel élément à un std : : vector, il est possible de se trouver 
dans le cas où il n’y a plus de place pour cet élément, autrement dit que la taille du 
std: : vector est égale à sa capacité. Lorsque cela se produit, le std: : vector alloue 
une nouvelle zone de mémoire plus vaste pour contenir ses éléments. Il transfère 
ensuite des éléments depuis la zone de mémoire actuelle vers la nouvelle. En C++98, 
ce transfert se faisait en copiant chaque élément depuis l’ancienne zone de mémoire 
vers la nouvelle, puis en détruisant les objets dans l’ancienne zone. Cette solution 
permettait à push_back d’offrir une forte garantie de sécurité vis-à-vis des exceptions : 
si une exception était lancée au cours de la copie des éléments, l’état du std : : vector 
restait inchangé car aucun des éléments qui se trouvaient dans l’ancienne zone de 
mémoire n’était détruit tant qu’ils n’avaient pas tous étés copiés dans la nouvelle zone. 

En C++ 1 1 , une optimisation naturelle serait de remplacer la copie des éléments 
du std: : vector par des déplacements. Malheureusement, cette solution fait courir 
un risque sur la sécurité de push_back vis-à-vis des exceptions. Si n éléments ont été 
déplacés depuis l’ancienne zone de mémoire et si une exception est lancée au cours 
du déplacement de l’élément n+1, le travail de push_back ne peut pas être mené à son 
terme. Cependant, le std: : vector d’origine a été modifié : n de ses éléments ont été 
déplacés. Sa restauration dans l’état précédent n’est pas toujours possible, car déplacer 
chaque élément dans la zone de mémoire initiale peut également déclencher une 
exception. 

Ce problème est sérieux, car le comportement du code ancien peut dépendre 
d’une garantie forte de sécurité de push_back face aux exceptions. Par conséquent, les 
implémentations de C+ + 1 1 ne peuvent pas simplement remplacer les opérations de 
copie de push_back par des déplacements, à moins qu’il ne soit possible d’assurer que 
ces déplacements ne génèrent aucune exception. Dans ce cas, ils pourront remplacer 
les copies et le seul effet secondaire sera des performances améliorées. 

std : : vector : : push_back exploite cette stratégie « de déplacement si c’est possible, 
mais de copie si c’est nécessaire », et ce n’est pas la seule fonction de la bibliothèque 
standard à procéder ainsi. C’est notamment le cas de celles qui offrent une garantie 
forte de sécurité vis-à-vis des exceptions en C++98 (comme std : : vector : : reserve, 
std: :deque: : i nsert, etc.). Elles remplacent toutes les appels aux opérations de copie 
en C++98 par des appels à des opérations de déplacement en C++ 1 1 , mais uniquement 
si celles-ci sont certaines de ne pas générer d’exception. Mais, comment une fonction 
peut-elle savoir qu’une opération de déplacement ne produira pas d’exception ? Elle 
vérifie évidemment si l’opération est déclarée noexcept 1 . 


1. En général, le contrôle est plutôt indirect. Les fonctions comme std: :vector: :push_back 
appellent std : :move_i f_noexcept, c’est-à-dire une variante de std::move qui, sous condi- 
tion, est convertie en une rvalue (voir le conseil 23), selon que le constructeur de dépla- 
cement du type est déclaré noexcept ou non. À son tour, std : :move_i f_noexcept consulte 
std : : i s_nothrowjnove_constructi bl e et la valeur de ce trait de type (voir le conseil 9) est fixée par 
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Les fonctions swap constituent un autre cas où noexcept est particulièrement 
attrayant. L’échange est une opération essentielle dans de nombreux algorithmes de 
la STL et on le rencontre également très souvent dans les opérations d’affectation 
par copie. En raison de sa généralisation, les optimisations permises par noexcept 
deviennent extrêmement intéressantes. Notez que la déclaration noexcept des fonc- 
tions swap de la bibliothèque standard dépend parfois de la déclaration noexcept des 
fonctions swap définies par l’utilisateur. Voici, par exemple, les déclarations des swap 
pour les tableaux et les std : : pai r dans la bibliothèque standard : 


template <class T, size_t N> 

void swap(T C&a ) [N] . // Voir 

T (&b)[N]) noexcept(noexcept(swap(*a, *b))); // ci-après. 

template <class Tl, class T2> 
struct pair ( 

void swap(pair& p) noexcept(noexcept(swap(first, p.first)) && 

noexcept ( swap (second, p. second ) ) ) ; 


Ces fonctions sont déclarées avec un noexcept conditionnel : elles seront noexcept 
uniquement si les expressions indiquées dans les clauses de leur noexcept sont 
noexcept. Prenons par exemple deux tableaux de Widget. L’invocation de swap pour ces 
deux tableaux sera noexcept uniquement si l’échange par swap des éléments individuels 
des tableaux est noexcept, autrement dit, si swap pour Widget est noexcept. L’auteur 
de la fonction swap de Widget détermine donc si l’échange de tableaux de Widget 
est noexcept. Ce statut détermine si d’autres swap, comme l’échange de tableaux de 
tableaux de Widget, sont aussi noexcept. De la même manière, l’échange de deux 
objets std: :pair qui contiennent des Widget sera noexcept si swap pour des Widget 
est noexcept. Vous le constatez, l’échange de structures de données de haut niveau ne 
sera en général noexcept que si l’échange de leurs composants de niveau inférieur est 
noexcept. Cela devrait vous inciter à proposer des fonctions swap noexcept dès que 
vous le pouvez. 

Nous espérons que vous êtes à présent enthousiasmé par les opportunités d’op- 
timisation offertes par noexcept. Nous allons malheureusement vous décevoir. Si 
l’optimisation est importante, l’exactitude l’est plus encore. Nous avons indiqué au 
début de ce conseil que noexcept fait partie de l’interface d’une fonction, qui pourra 
être déclarée noexcept uniquement si nous sommes prêts à garder son implémentation 
noexcept sur le long terme. Si nous déclarons une fonction noexcept et regrettons 
ensuite ce choix, les conséquences sont peu réjouissantes. Nous pouvons retirer 
noexcept de la déclaration de la fonction (c’est-à-dire changer son interface), mais 
les risques de dysfonctionnement dans le code client ne sont pas négligeables. Nous 
pouvons modifier l’implémentation de façon qu’une exception puisse être générée, 


le compilateur, selon que le constructeur de déplacement a une désignation noexcept (ou throw( )) 
© ou non. 
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tout en gardant la spécification d’exception d’origine (mais alors inexacte). Dans ce 
cas, le programme sera terminé si une exception sort de la fonction. Nous pouvons 
également nous résigner à conserver la version existante, en oubliant ce qui nous avait 
initialement conduit à vouloir modifier l’implémentation. Aucune de ces options n’est 
séduisante. 

Le fait est que la plupart des fonctions sont neutres envers les exceptions. Elles ne 
lancent aucune exception elles-mêmes, mais les fonctions qu’elles appellent peuvent 
en générer. Lorsque cela se produit, la fonction neutre permet à l’exception qui a été 
levée de remonter la chaîne des appels jusqu’à un gestionnaire qui saura la traiter. Les 
fonctions neutres envers les exceptions ne sont jamais noexcept, car elles peuvent 
émettre des exceptions « qui ne font que passer ». Par conséquent, la désignation 
noexcept est absente de la plupart des fonctions. 

Cependant, certaines fonctions ont des implémentations naturelles qui ne génèrent 
aucune exception. Pour quelques autres, comme les opérations de déplacement et swap, 
être noexcept apporte un tel bénéfice qu’il vaut la peine de les mettre en œuvre de 
manière noexcept, si tant est que ce soit possible 1 . Lorsque nous pouvons affirmer 
qu’une fonction ne produira jamais d’exception, nous devons la déclarer noexcept. 

Nous avons indiqué que certaines fonctions ont une implémentation noexcept 
naturelle. Détourner la mise en œuvre d’une fonction afin de permettre une décla- 
ration noexcept, c’est un peu le monde à l’envers. C’est placer la charrue avant 
les bœufs. C’est l’arbre qui cache la forêt. Choisissez votre métaphore préférée... Si 
l’implémentation normale d’une fonction peut lancer des exceptions (par exemple 
en invoquant une fonction qui peut elle-même en lever), tout le travail que nous 
devrons effectuer pour masquer ce fait au code appelant (par exemple intercepter 
toutes les exceptions et les remplacer par des codes d’état ou des valeurs de retour 
particulières) va non seulement compliquer l’implémentation de la fonction mais 
également le code appelant. Par exemple, il faudra que celui-ci vérifie les codes d’état 
ou les valeurs de retour spéciales. Le coût d’exécution de ces complications (par 
exemple des branchements supplémentaires, des fonctions plus longues qui sollicitent 
énormément les caches d’instructions, etc.) peut remettre en question l’amélioration 
des performances que nous pensions obtenir grâce à noexcept, sans oublier que le code 
source risque d’être plus difficile à comprendre et à maintenir. Voilà une ingénierie 
logicielle plutôt médiocre. 

Il est tellement important que certaines fonctions soient noexcept qu’elles le sont 
par défaut. En C++98, les bonnes pratiques interdisaient aux fonctions de libération 
de la mémoire (c’est-à-dire operator del ete et operator del ete[ ] ) et aux destructeurs 
de générer des exceptions. En C++ 11, cette règle de style est devenue une règle 


1. Les interfaces des opérations de déplacement sur les conteneurs de la bibliothèque standard 
ne sont pas spécifiées noexcept. Toutefois, les programmeurs peuvent renforcer les spécifications 
d’exceptions sur les fonctions de la bibliothèque standard et, en pratique, il est courant qu’au moins 
quelques opérations de déplacement sur les conteneurs soient déclarées noexcept. Cette pratique 
illustre parfaitement le conseil prodigué ici. En ayant découvert que des opérations de déplacement 
sur les conteneurs pouvaient être écrites sans déclencher des exceptions, les programmeurs les 
déclarent souvent noexcept même si la norme ne les y oblige pas. 
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du langage. Par défaut, toutes les fonctions de désallocation de la mémoire et les 
destructeurs, qu’ils soient définis par l’utilisateur ou générés par le compilateur, sont 
implicitement noexcept. Il est donc inutile de les déclarer noexcept (le contraire 
ne fera pas de mal mais sera juste peu conventionnel). Il existe un seul cas où 
un destructeur n’est pas implicitement noexcept : lorsqu’une donnée membre de la 
classe (y compris les membres hérités et ceux contenus à l’intérieur d’autres données 
membres) a un type qui stipule expressément que son destructeur peut générer des 
exceptions (par exemple le déclare « noexcept (f al se) »). De tels destructeurs sont 
plutôt rares. La bibliothèque standard n’en contient aucun et si le destructeur d’un 
objet utilisé par cette bibliothèque (par exemple, parce qu’il se trouve dans un 
conteneur ou qu’il a été passé à un algorithme) génère une exception, le comportement 
du programme est indéfini. 

Il est bon de savoir que certains concepteurs d’interfaces de bibliothèques font une 
différence entre les fonctions ayant des contrats étendus et celles ayant des contrats 
restreints. Une fonction avec un contrat étendu ne fixe aucune condition préalable. 
Elle peut être appelée quel que soit l’état du programme et elle n’impose aucune 
contrainte sur les arguments transmis par l’appelant 1 . Ces fonctions n’ont jamais un 
comportement indéfini. 

Les fonctions qui n’ont pas de contrat étendu ont un contrat restreint. Dans ce cas, 
si une condition préalable n’est pas respectée, le résultat de l’appel à la fonction n’est 
pas défini. 

Si nous développons une fonction avec un contrat étendu et savons qu’elle 
ne générera aucune exception, il est facile de suivre le présent conseil et de la 
déclarer noexcept. Le cas d’une fonction avec un contrat restreint est plus complexe. 
Supposons, par exemple, que nous écrivions une fonction f qui prend unstd::string 
en paramètre et supposons que son implémentation naturelle ne déclenche jamais 
d’exception. Tout est réuni pour que f soit déclarée noexcept. 

Supposons à présent que f définisse une précondition : la longueur du paramètre 
std : : stri ng ne doit pas dépasser 32 caractères. Si f est appelée avec un std : : s tri ng 
de longueur supérieure, son comportement est indéfini car, par définition, le non- 
respect d’une précondition conduit à un comportement indéfini, f n’est pas obligé 
de vérifier la longueur du paramètre, car les fonctions peuvent supposer que leurs 
préconditions sont remplies. (C’est à l’appelant de respecter les hypothèses.) Même 
avec une précondition, il semble approprié de déclarer f noexcept : 

I void f(const std::string& s) noexcept; // Précondition : 

// s.lengthO <= 32. 


1 . « Quel que soit l’état du programme » et « aucune contrainte » ne légitiment en aucun cas les 
programmes dont le comportement est déjà indéfini. Par exemple, std : : vector : :size a un contrat 
étendu, mais cela ne veut pas dire que son comportement sera correct si elle est invoquée avec une 
zone de mémoire quelconque qui a été convertie de façon forcée en un std : : vector. Le résultat de 
la conversion de type est indéfini et il n’y a aucune garantie de comportement pour le programme 
© qui effectue cette conversion. 
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Mais supposons que le développeur de f décide de contrôler le respect de la 
précondition. Cette vérification n’est pas obligatoire, mais elle n’est pas interdite 
et peut même être utile, par exemple pendant les tests du système. Il est en général 
plus facile de déboguer une exception qui a été lancée que d’essayer de découvrir 
l’origine d’un comportement indéfini. Comment peu ton signaler le non-respect d’une 
précondition afin que l’outil de test ou le gestionnaire d’erreurs du code client puisse 
le détecter ? Une solution simple serait de lancer une exception « non-respect d’une 
précondition », mais, si f est déclarée noexcept, cela n’est pas possible. En effet, 
lancer une exception conduirait alors à la terminaison du programme. C’est pourquoi 
les concepteurs de bibliothèques qui distinguent les contrats étendus et les contrats 
restreints réservent généralement noexcept aux fonctions qui ont un contrat étendu. 

Pour finir, revenons sur le fait que le compilateur n’apporte en général aucune aide 
pour l’identification des incohérences entre l’implémentation d’une fonction et sa 
spécification d’exception. Examinons le code suivant, qui est parfaitement valide : 


void setupO; 
void cleanupO; 

void doWorkO noexcept 
{ 

setup( ) ; 


cl eanup( ) ; 


// Fonctions définies ailleurs. 

// Mettre en place les actions à réaliser. 
// Effectuer les actions. 

// Faire le ménage après les actions. 


Bien qu’elle appelle les fonctions setup et cleanup qui ne sont pas spécifiées 
noexcept, doWork est déclarée noexcept. Cela peut sembler contradictoire, mais il 
est possible que la documentation de setup et de cl eanup précise qu’elles ne lancent 
jamais d’exception même si elles ne sont pas déclarées noexcept. Il peut y avoir de 
bonnes raisons à cela, par exemple le fait qu’elles se trouvent dans une bibliothèque 
écrite en C. (Même des fonctions de la bibliothèque standard C qui ont été déplacées 
dans l’espace de noms std n’ont pas de spécifications d’exception. Par exemple, 
std::strlen n’est pas déclarée noexcept.) Elles peuvent également faire partie d’une 
bibliothèque C++98 pour laquelle il avait été décidé de ne pas utiliser les spécifications 
d’exceptions de C++98 et qui n’a pas été revue pour C+ + 1 1. 

Puisque les fonctions noexcept peuvent avoir de bonnes raisons de se fonder sur du 
code sans garantie noexcept, C++ autorise l’écriture d’un tel code et les compilateurs 
n’y voient généralement rien à redire. 


À retenir 

• noexcept fait partie de l'interface d'une fonction et le code appelant peut donc 
en dépendre. 

• Les fonctions noexcept présentent de plus grandes possibilités d'optimisation 
que les fonctions non noexcept. 
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• noexcept est particulièrement intéressant avec les opérations de déplacement, 
swap, les fonctions de désallocation de la mémoire et les destructeurs. 

• La plupart des fonctions affichent une neutralité envers les exceptions plutôt 

que noexcept. 


CONSEIL N° 15. UTILISER CONSTEXPR DÈS QUE POSSIBLE 

Si nous devions élire le nouveau mot clé le plus déroutant de C+ + 11, constexpr 
serait probablement le vainqueur. Appliqué à des objets, il s’agit essentiellement d’une 
version renforcée de const. En revanche, appliqué à des fonctions, sa signification est 
assez différente. Nous allons couper court à toute confusion car, lorsque constexpr 
correspond à ce que nous voulons exprimer, il devient indispensable. 

Conceptuellement, constexpr indique non seulement qu’une valeur est une 
constante mais aussi qu’elle est connue au moment de la compilation. Néanmoins, 
le concept n’est pas tout car, lorsque constexpr est appliquée aux fonctions, les 
choses sont plus nuancées. De peur de dévoiler la scène finale, nous allons pour le 
moment nous contenter de préciser qu’il ne faut pas supposer que les résultats des 
fonctions constexpr sont des const, ni que leurs valeurs sont connues au moment de 
la compilation. Plus étrangement, ces deux aspects sont des fonctionnalités. En réalité, 
il est préférable que les fonctions constexpr ne soient pas obligées de produire des 
résultats const ou connus à la compilation ! 

Commençons tout d’abord par les objets constexpr. De tels objets sont bien const 
et ils ont bien des valeurs connues au moment de la compilation. (D’un point de vue 
technique, leurs valeurs sont déterminées au cours de la traduction, qui regroupe la 
compilation et l’édition de liens. Cependant, à moins que vous ne développiez des 
compilateurs ou des éditeurs de liens pour C++, cela ne vous concerne pas et vous 
pouvez continuer à écrire vos programmes comme si les valeurs des objets constexpr 
étaient déterminées au moment de la compilation.) 

Les valeurs connues pendant la compilation bénéficient de privilèges. Par exemple, 
elles peuvent être placées dans une zone de mémoire en lecture seule, ce qui, pour les 
développeurs de systèmes embarqués notamment, peut avoir une importance considé- 
rable. Dans un champ d’application plus large, les valeurs entières qui sont constantes 
et connues à la compilation peuvent être employées dans tous les contextes où C++ 
a besoin d’une expression constante entière. Il s’agit notamment de la spécification de 
la taille d’un tableau, d’un argument entier d’un template (y compris la dimension 
d’un objet std : : array), des valeurs d’un énumérateur, des spécificateurs d’alignement, 
etc. Si nous souhaitons employer une variable dans toutes ces utilisations, nous la 
déclarerons avec constexpr car le compilateur s’assurera ensuite qu’elle a une valeur 
pendant la compilation : 


int s z ; 


// Variable non constexpr. 
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constexpr auto arraySizel = sz; 

std: :array<int, sz> datai; 
constexpr auto arraySize2 = 10; 


Il Erreur ! La valeur de sz n’est 
Il pas connue à la compilation. 

Il Erreur ! Problème identique. 

Il Parfait, 10 est une constante 
Il connue à la compilation. 


std; :array<int, arraySize2> data2; Il Parfait, arraySize2 est déclarée 

Il constexpr. 

Notez que const n’offre pas la même garantie que constexpr. En effet, les objets 
const ne sont pas nécessairement initialisés avec des valeurs connues à la compilation ; 


int sz; // Comme précédemment. 


const auto arraySize = sz; // Parfait, arraySize est une copie 

// constant de sz. 

std: :array<int, arraySize) data; // Erreur ! La valeur de arraySize 

// n’est pas connue à la compilation. 

Pour faire simple, tous les objets constexpr sont des const, mais tous les objets 
const ne sont pas des constexpr. Si nous voulons que le compilateur garantisse qu’une 
variable possède une valeur pouvant être utilisée dans des contextes qui exigent des 
constantes connues à la compilation, nous devons employer non pas const mais 
constexpr. 

Les scénarios d’utilisation des objets constexpr deviennent plus intéressants 
lorsque des fonctions constexpr entrent en scène. De telles fonctions produisent 
des constantes connues à la compilation lorsqu’elles sont appelées avec des constantes 
connues à la compilation. Si elles sont appelées avec des valeurs connues uniquement 
au moment de l’exécution, elles produisent des valeurs connues à l’exécution. Vous 
pourriez penser que cela revient à ignorer ce qu’elles feront, mais cette réflexion est 
erronée. Voici la bonne vision : 

• Les fonctions constexpr peuvent être employées dans les contextes qui 
demandent des constantes connues à la compilation. Si les valeurs des 
arguments transmis à une fonction constexpr employée dans un tel 
contexte sont connues à la compilation, le résultat sera déterminé pendant 
la compilation. Si l’une des valeurs des arguments n’est pas connue à la 
compilation, le code sera refusé. 

• Lorsqu’une fonction constexpr est appelée avec une ou plusieurs valeurs 
inconnues au moment de la compilation, elle se comporte comme une fonction 
normale, en déterminant son résultat au cours de l’exécution. Nous n’avons 
donc pas besoin de deux fonctions, l’une pour des constantes connues à la 
compilation et l’autre pour les autres valeurs, pour effectuer la même opération. 
La seule fonction constexpr suffit. 
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Supposons que nous ayons besoin d’une structure de données pour mémoriser 
les résultats d’une expérience qui peut être menée sous différentes conditions. Par 
exemple, le niveau d’éclairage peut être élevé, faible ou nul au cours de l’expérience, 
tout comme la vitesse du ventilateur, la température, etc. S’il existe n conditions 
environnementales pertinentes pour l’expérience, chacune avec trois états possibles, 
le nombre de combinaisons est égal à 3 n . Pour stocker les résultats obtenus avec toutes 
ces combinaisons, il nous faut une structure de données avec une place suffisante 
pour 3 n valeurs. En supposant que chaque résultat soit un int et que n est connu 
(ou puisse être calculé) à la compilation, un std: :array peut être une structure de 
données convenable. Nous devons cependant calculer 3" pendant la compilation. 
La bibliothèque standard de C++ fournit std: :pow, qui correspond à la fonction 
mathématique requise, mais, dans notre cas, elle pose deux problèmes. Premièrement, 
std: :pow manipule des types à virgule flottante alors que nous avons besoin d’un 
résultat entier. Deuxièmement, std : : pow n’est pas constexpr (autrement dit, rien ne 
garantit qu’elle retournera un résultat au moment de la compilation si elle est appelée 
avec une valeur connue à la compilation). Nous ne pouvons donc pas l’employer pour 
fixer la taille d’un std : : array. 

Heureusement, nous sommes capables d’écrire la fonction pow dont nous avons 
besoin, mais nous la montrerons plus loin. Commençons par présenter sa déclaration 
et son utilisation : 

constexpr 

int pow(int base, int exp) noexcept 


constexpr auto numConds = 5; // Nombre de conditions. 

std: :array<int, pow(3, numConds)> results; // results comprend 

// 3"numConds éléments. 

Rappelons que le mot clé constexpr placé devant pow signifie non pas que cette 
fonction retourne une valeur const, mais que si base et exp sont des constantes 
connues à la compilation, le résultat de pow peut être utilisé comme une constante au 
moment de la compilation. Si base et/ou exp ne sont pas des constantes connues à la 
compilation, le résultat de pow sera déterminé à l’exécution. Autrement dit, la fonction 
pow peut non seulement être appelée à la compilation pour effectuer des opérations 
comme calculer la taille d’un std: : array, mais également pendant l’exécution : 

auto base = readFromDBC "base" ) ; // Obtenir ces valeurs 

auto exp = readFromDB( "exponent" ) ; // à l’exécution. 

auto baseToExp = pow(base, exp); // Appeler la fonction pow 

// à 1 'exécution. 

Puisque les fonctions constexpr doivent être en mesure de renvoyer des résultats 
pendant la compilation lorsqu’elles sont appelées avec des valeurs connues à ce 


// pow est une fonction constexpr 
// qui ne lève pas d’exception. 

// Implémentation ci-après. 



Copyright © 2016 Dunod. 



Chapitre 3. Vers un C++ moderne 


moment-là, leur implémentation est soumise à plusieurs contraintes. Ces restrictions 
diffèrent entre C+ + 11 et C+ + 14. 

En C+ + 1 1 , les fonctions constexpr ne doivent contenir qu’une seule instruction 
exécutable : un return. Cette contrainte n’est pas trop forte, car deux astuces 
permettent d’étendre les possibilités d’expression dans les fonctions constexpr. Pre- 
mièrement, l’opérateur conditionnel « ? : » peut remplacer des instructions if -el se 
et, deuxièmement, la récursion peut remplacer les boucles. Voici donc une manière 
d’implémenter pow : 


constexpr int pow(int base, int exp) noexcept 
( 

return (exp == 0 ? 1 : base * pow(base, exp - 1)); 


Ce code fonctionne, mais il est difficile d’imaginer qu’un programmeur autre qu’un 
amateur pur et dur de la programmation fonctionnelle puisse l’apprécier. En C+ + 14, 
les restrictions sur les fonctions constexpr sont moindres et l’implémentation suivante 
devient possible : 


constexpr int pow(int base, int exp) noexcept // C++14. 

{ 

auto resuit = 1; 

for (int i =0; i < exp; ++i) resuit *= base; 
return resuit; 


Les fonctions constexpr ont pour obligation de prendre et de retourner des littéraux, 
autrement dit des types dont il est possible de déterminer la valeur au moment de 
la compilation. En C+ + 1 1, c’est le cas de tous les types intégrés, à l’exception de 
void. Les types définis par l’utilisateur peuvent également être des littéraux, car les 
constructeurs et d’autres fonctions membres peuvent être constexpr : 


class Point ( 
publ ic: 

constexpr Point(double xVal = 0, double yVal = 0) noexcept 
: x(xVal), y(yVal) 


constexpr double xValueO const noexcept { return x; 1 

constexpr double yValueO const noexcept ( return y; 1 

void setX(double newX) noexcept I x = newX; I 

void setY(double newY) noexcept { y = newY ; ) 

pri vate: 
double x, y; 
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Dans cet exemple, le constructeur de Poi nt peut être déclaré constexpr car, si les 
arguments qui lui sont passés sont connus au moment de la compilation, les valeurs 
des données membres de l’objet Point construit peuvent également être connues à ce 
moment-là. Les Poi nt initialisés de cette manière peuvent donc être constexpr : 

constexpr Point pl(9.4, 27.7); // Parfait, "exécuter" le constructeur 

// constexpr à la compilation. 

constexpr Point p2(28.8, 5.3); // Également parfait. 

De même, les accesseurs xValue et yValue peuvent être constexpr, car si ces 
méthodes sont invoquées sur un objet Poi nt avec une valeur connue à la compilation 
(par exemple un objet constexpr Poi nt), les valeurs des données membres x et y sont 
également connues pendant cette phase. Il est donc possible d’écrire des fonctions 
constexpr qui invoquent les accesseurs de Poi nt et d’initialiser des objets constexpr 
avec les résultats obtenus : 

constexpr 

Point midpoint(const Point& pl, const Poi n t& p2) noexcept 

{ 

return i (pl.xValueO + p2.xValue()) / 2, // Appeler les fonctions 

(pl.yValueO + p2.yValue()) / 2 ); // membres constexpr. 

1 

constexpr auto mid = mi dpoi nt ( pl , p2); // Initialiser un objet 

// constexpr avec le résultat 
// d’une fonction constexpr. 

Tout cela est très intéressant. En effet, même si l’initialisation de l’objet mid 
implique des appels à des constructeurs, des accesseurs et une fonction non membre, 
il peut être créé dans une zone de mémoire en lecture seule ! Nous pouvons donc 
employer une expression comme mid.xVal ue( ) * 10 dans un argument de template 
ou dans une expression qui précise la valeur d’un énumérateur 1 ! Par ailleurs, la 
démarcation habituellement nette entre le travail effectué à la compilation et celui 
effectué au cours de l’exécution devient plus floue. Certains calculs traditionnellement 
effectués pendant l’exécution peuvent à présent être réalisés à la compilation. Plus 
la quantité de code concernée par ce changement sera importante, plus l’exécution 
du programme sera rapide. (En revanche, la compilation risque de prendre plus de 
temps.) 

En C++11, deux contraintes empêchent de déclarer constexpr les fonctions 
membres setX et setY de Point. Premièrement, elles modifient l’objet qu’elles 
manipulent et, en C+ + 1 1, les fonctions membres constexpr sont implicitement const. 


1. Puisque Poi nt : : xVa 1 ue renvoie un double, mid.xValue( ) * 10 est aussi de type double. Les 
nombres à virgule flottante ne peuvent pas servir à instancier des templates ni à spécifier les valeurs 
d’un énumérateur, mais ils peuvent être intégrés à des expressions plus longues qui impliquent des 
entiers. Par exemple, nous pouvons employer stati c_cast<i ntXmid .xVal ue( ) * 10) pour instancier 
© un template ou fixer la valeur d’un énumérateur. 
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Deuxièmement, elles spécifient un type de retour void, qui n’est pas un littéral en 
C++11. Puisque ces deux restrictions sont levées en C++14, dans cette version du 
langage même les mutateurs de Poi nt peuvent être constexpr : 

class Point { 
publ ic: 


constexpr void setX(double newX) noexcept // C++14. 
( x = newX; I 

constexpr void setY(double newY) noexcept // C++14. 
I y = newY; ) 


Cela nous autorise à écrire des fonctions telles que la suivante : 

// Retourner l’opposé de p par rapport à l’origine (C++14). 
constexpr Point reflection(const Points p) noexcept 
( 

Point resuit; Il Créer un Point non const. 

resuit. setX( -p.xVal ue( )) ; Il Fixer ses valeurs x et y. 

resul t .setY( -p.yVal ue( ) ) ; 

return resuit; // En renvoyer une copie. 


Voici un exemple de code client : 

constexpr Point p 1 ( 9 . 4 , 27.7); // Comme précédemment, 

constexpr Point p2 ( 28 . 8 , 5.3); 
constexpr auto mid = mi dpoi nt ( pl . p2); 

constexpr auto reflectedMid = // La valeur de reflectedMid 

reflection(mid) ; // est (-19.1 -16.5) et connue 

// à la compilation. 

Ce conseil recommande d’utiliser constexpr dès que c’est possible et nous espérons 
que vous comprenez à présent pourquoi ; les objets et les fonctions constexpr peuvent 
être employés dans un plus grand nombre de contextes que les objets et les fonctions 
non constexpr. 

Il est important de noter que constexpr fait partie de l’interface d’un objet d’une 
fonction. Ce mot clé signifie « je peux être utilisé dans tout contexte où C++ a besoin 
d’une expression constante ». Si nous déclarons un objet ou une fonction constexpr, 
le code client peut l’employer dans de tels contextes. Si nous décidons ensuite que la 
déclaration constexpr était une erreur et que nous la supprimons, il est possible que de 
grandes quantités de code client ne compilent plus. (Le simple ajout d’entrées-sorties 
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à une fonction pour le débogage ou le réglage des performances peut conduire un tel 
problème, car les instructions d’entrées-sorties sont généralement interdites dans les 
fonctions constexpr.) C’est à vous de décider si, en utilisant constexpr, vous acceptez 
de respecter sur le long terme les contraintes que cela impose sur les objets et les 
fonctions concernés. 


À retenir 

• Les objets constexpr sont const et sont initialisés avec des valeurs connues au 
moment de la compilation. 

• Les fonctions constexpr peuvent générer des résultats pendant la compilation 
si elles sont appelées avec des arguments dont les valeurs sont connues à ce 
moment-là. 

• Les objets et les fonctions constexpr sont utilisables dans un éventail de contextes 
plus large que les objets et les fonctions non constexpr. 

• constexpr fait partie de l'interface de l'objet ou de la fonction. 


CONSEIL N° 1 6 . RENDRE LES FONCTIONS MEMBRES 
CONST SÛRES VIS-À-VIS DES THREADS 


Les personnes qui travaillent dans un domaine mathématique pourraient trouver 
commode de disposer d’une classe qui représente des polynômes. Elle pourrait offrir une 
fonction qui calcule les racines d’un polynôme, c’est-à-dire les valeurs pour lesquelles 
l’évaluation du polynôme est égale à zéro. Puisque cette fonction ne modifierait pas le 
polynôme, il serait naturel de la déclarer const : 


T3 

O 


// Structure de données qui contient 
// les valeurs pour lesquelles le 
// polynôme est égal à 0 (voir le 
// conseil 9 pour des infos sur "using"). 

RootsType rootsO const; 


1; 


class Polynomial I 
publ ic: 

using RootsType = 
std : :vector<double>; 


Déterminer les racines d’un polynôme peut être un calcul lourd, qui ne doit donc 
pas être effectué inutilement. S’il doit être lancé, il est préférable de ne pas le répéter 
plusieurs fois. Nous allons donc placer les racines du polynôme dans un cache après 
leur calcul et nous allons implémenter roots de façon qu’elle retourne ces valeurs en 
cache. Voici l’approche de base : 


Copyright © 2016 Dunod. 



Chapitre 3. Vers un C++ moderne 


class Polynomial { 
public: 

using RootsType = std : : vectoKdoubl e> : 

RootsType roots() const 
( 

if ( IrootsAreValid) { // Si le cache est invalide 

// déterminer les racines, et 
// les mémoriser dans rootVals. 

rootsAreVal id = true; 


return rootVals; 

1 


private: 

mutable bool rootsAreVal idl false }; // Voir le conseil 7 pour des 

mutable RootsType rootVals! I; // infos sur les initialiseurs. 

1; 

Conceptuellement, roots ne modifie pas l’objet Polynomial qu’elle manipule, 
mais, dans sa gestion du cache, elle peut modifier rootVal s et rootsAreVal i d. Il s’agit 
d’un cas classique d’utilisation de mutable et c’est pourquoi nous l’utilisons dans la 
déclaration de ces données membres. 

Imaginons à présent que deux threads appellent simultanément roots sur un objet 

Polynomial : 


Polynomial p; 


/* Thread 1 */ /* Thread 2 */ 

auto rootsOfP = p.rootsO; auto val sGi vingZero = p.rootsO; 

Ce code client est parfaitement envisageable, roots est une fonction membre 
const, qui représente donc une opération de lecture. Plusieurs threads peuvent 
effectuer en toute sécurité une opération de lecture sans synchronisation. Tout au 
moins, c’est ainsi que cela devrait se passer. Ce n’est pas le cas de notre exemple, 
car, dans la méthode roots, l’un ou l’autre de ces threads peut essayer de modifier 
les données membres rootsAreVal i d et rootVals. Autrement dit, ce code peut 
présenter des threads différents qui lisent et écrivent la même zone de mémoire sans 
synchronisation ; voilà la définition d’une situation de concurrence sur les données. 
Ce code a donc un comportement indéfini. 

Le problème vient du fait que roots est déclarée const sans qu’elle soit sûre vis-à-vis 
des threads. Puisque la déclaration const est aussi correcte en C+ + 1 1 qu’elle le serait 
en C++98 (obtenir les racines d’un polynôme ne change pas la valeur du polynôme), 
la rectification doit se faire au niveau de la sécurité vis-à-vis des threads. 
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Pour résoudre ce problème, l’approche classique consiste à mettre en place un 
mutex : 


class Polynomial I 
publ ic: 

using RootsType = std: :vector<double>; 

RootsType rootsO const 
I 

std: :lock_guard<std: :mutex> g ( m ) ; II Verrouiller le mutex. 

if ( ! rootsAreVal id) I II Si le cache est invalide 

Il calculer/mémoriser les racines. 

rootsAreVal id = true; 


return rootVals; 

1 


Il Libérer le mutex. 


private: 

mutable std: imutex m; 

mutable bool rootsAreVal idl false ); 
mutable RootsType rootValsl); 


T3 
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Le std : : mutex m est déclaré mutabl e, car son verrouillage et sa libération se font 
avec des fonctions membres non const et, dans roots (une fonction membre const), 
m serait sinon considéré comme un objet const. 

Notez que std : : mutex étant un type réservé au déplacement (c’est-à-dire un type qui 
accepte les déplacements mais pas les copies), l’ajout de m à Polynomi al conduit cette 
classe à perdre sa faculté à être copiée. En revanche, elle peut toujours être déplacée. 

Dans certains cas, la solution du mutex est exagérée. Par exemple, si nous 
comptons simplement le nombre d’appels à une fonction membre, un compteur 
std: :atomic (c’est-à-dire un compteur dont les opérations sont vues par d’autres 
threads comme indivisibles ; voir le conseil 40) sera souvent plus économe. (Le coût 
réel de cette solution dépend du matériel utilisé et de l’implémentation des mutex dans 
la bibliothèque standard.) Voici comment se servir d’un std : : atomi c pour compter 
des appels : 

class Point I // Point en 2D. 

publ ic: 


double di stanceFromOri gi n ( ) const noexcept // Voir le conseil 14 
I // pour noexcept. 


++callCount; 

return std::sqrt((x * x) + (y * y)); 


// Incrémentation atomique. 
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p r i v a t e : 

mutable std: :atomic<unsigned> callCount{ 0 }; 

double x, y; 

}; 

À l’instar des std : :mutex, les std : : atomi c peuvent uniquement être déplacés. La 
présence de callCount dans Point signifie donc que Point est un type réservé au 
déplacement. 

Puisque les opérations sur les variables std : : atomi c sont souvent moins onéreuses 
que l’acquisition et la libération d’un mutex, nous pourrions être tentés de compter 
sur les std : : atomi c bien plus qu’il ne le faudrait. Par exemple, dans une classe qui 
met en cache un i nt long à calculer, nous pourrions imaginer utiliser deux variables 
std : : atomi c à la place d’un mutex : 


class Widget I 
publ i c : 


int magicValuei ) const 
1 

if (cacheValid) return cachedValue; 
else ( 

auto vall = expensi veComputationl( ) ; 
auto val 2 = expensiveComputation2( ) ; 

cachedValue = vall + va 1 2 ; // Houlà, partie 1. 

cacheValid = true; // Houlà, partie 2. 

return cachedValue; 


pri vate: 

mutable std: :atomic<bool> cacheValid) false 1; 
mutable std: :atomic<int> cachedValue; 


Ce code fonctionne, mais il travaille parfois plus qu’il ne le devrait. Examinons la 
situation suivante : 

• Un thread appelle Widget: :magi cVal ue, voit que cacheValid est false, effectue 
deux calculs intensifs et affecte la somme de leurs résultats à cachedVal ue. 

• À ce stade, un second thread appelle Widget : :magi cVal ue, voit également que 
cacheVal id est false et réalise donc les mêmes calculs que le premier thread 
vient de terminer. (Ce « second thread » pourrait en réalité correspondre à 
plusieurs autres threads.) 

Un tel fonctionnement va à l’encontre de l’objectif d’un cache. Inverser l’ordre des 
affectations de cachedVal ue et de CacheVal id supprime ce problème, mais le résultat 
est pire encore : 


Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 16 . Rendre les fonctions membres const sûres vis-à-vis des threads 



class Widget ( 
public: 


int magicVal ue( ) const 
I 

if (cacheVal id) return cachedVal ue; 
else ( 

auto vall = expensiveComputationK); 
auto va 1 2 = expensiveComputation2( ) ; 

cacheValid = true; // Houlà, partie 1. 

return cachedValue = vall + va 1 2 ; // Houlà, partie 2. 


Imaginons que cacheVal i d soit fal se et qu’ensuite : 

• Un thread appelle Widget: :magicValue et poursuit son exécution jusqu’à la 
ligne où cacheValid est fixé à true. 

• À ce moment-là, un second thread appelle Wi dget : : ma g i cVal ue et vérifie 
cacheValid. Puisqu’il vaut true, le thread renvoie cachedValue, même si le 
premier thread n’a pas encore fixé sa valeur. La valeur retournée est donc 
incorrecte. 

Voici la leçon à retenir. Lorsqu’une seule variable ou zone de mémoire a besoin 
d’une synchronisation, il est possible d’employer un std : : atomi c. En revanche, lorsque 
deux variables ou zones de mémoire sont impliquées et doivent être manipulées 
comme une seule unité, il faut opter pour un mutex. Appliquons ce principe à 
Wi dget: :magi cVal ue : 


class Widget I 
publ ic: 


int magicVal ue( ) const 
I 

std: :lock_guard<std: :mutex> guard(m); Il Verrouiller m. 

if (cacheValid) return cachedValue; 
else ( 

auto vall = expensiveComputationK); 
auto val 2 = expensiveComputation2( ) ; 
cachedValue = vall + val 2 ; 
cacheVal id = true; 
return cachedValue; 


// Libérer m. 
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pri vate: 

mutable std: :mutex m; 

mutable int cachedValue; 
mutable bool cacheVal i d { false 


Il N’est plus atomique. 
Il N’est plus atomique. 


Ce conseil se fonde sur l’hypothèse que plusieurs threads peuvent invoquer 
simultanément une fonction membre const sur un objet. Si nous écrivons une fonction 
membre const pour laquelle ce n’est pas le cas - pour laquelle nous pouvons garantir 
que jamais plusieurs threads ne l’invoqueront sur un même objet -, sa sécurité vis-à-vis 
des threads n’a pas d’importance. Par exemple, les fonctions membres d’une classe 
conçue pour une utilisation exclusivement monothread n’ont pas besoin d’être sûres 
vis-à-vis des threads. Dans ce cas, nous pouvons éviter les coûts associés aux mutex et 
aux std : : atomi c, et oublier que les classes qui les utilisent ne peuvent plus être copiées 
mais uniquement déplacées. Toutefois, de tels scénarios sont de moins en moins 
fréquents et vont même se raréfier. Il vaut mieux parier sur le fait que les fonctions 
membres const seront sujettes aux exécutions concurrentes et qu’elles doivent donc 
être sûres vis-à-vis des threads. 


À retenir 

• Les fonctions membres const doivent être sûres vis-à-vis des threads, sauf s'il 
est certain quelles ne seront jamais utilisées dans un contexte de concurrence. 

• Les variables std:: atomi c pourront conduire à de meilleures performances 
qu'un mutex, mais elles ne conviennent que lors de la manipulation d'une seule 
variable ou zone de mémoire. 


CONSEIL N° 1 7. COMPRENDRE LA GÉNÉRATION 
D'UNE FONCTION MEMBRE SPÉCIALE 

Dans le jargon C++ officiel, les fonctions membres spéciales désignent les fonctions que 
le compilateur C++ est disposé à générer de lui-même. En C++98, ces fonctions sont 
au nombre de quatre : le constructeur par défaut, le destructeur, le constructeur de 
copie et l’opérateur d’affectation par copie. Elles sont générées uniquement en cas de 
besoin, c’est-à-dire si du code les utilise sans qu’elles soient déclarées explicitement 
dans la classe. Un constructeur par défaut est généré uniquement si la classe n’en 
déclare aucun. (Cela évite que le compilateur ne crée un constructeur par défaut alors 
que nous avons spécifié que le constructeur de la classe doit avoir des arguments.) Les 
fonctions membres spéciales générées sont implicitement publiques et 1 n 1 ine. Elles 
ne sont pas virtuelles, sauf si la fonction en question est le destructeur d’une classe qui 
dérive d’une classe de base dont le destructeur est virtuel. Dans ce cas, le destructeur 
créé par le compilateur pour la classe dérivée est également virtuel. 

Mais vous savez déjà tout cela ; c’est de l’histoire ancienne. Mais les temps ont 
changé et les règles de génération d’une fonction membre spéciale en C++ ont évolué. 
Il est important de les connaître, car savoir quand le compilateur insère discrètement 
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des fonctions membres dans nos classes est essentiel à une programmation efficace en 
C++. 

Depuis C++ 1 1 , le club des fonctions spéciales comprend deux membres supplémen- 
taires : le constructeur de déplacement et l’opérateur d’affectation par déplacement. 
Voici leur signature : 


class Widget { 
public: 

Widget(Widget&& rhs); 

Widget& operator=(Widget&& rhs); 


// Constructeur de déplacement. 

// Opérateur d’affectation 
// par déplacement. 


-o 

O 


© 


Les règles qui gouvernent leur génération et comportement sont comparables 
à celles de leurs homologues pour la copie. Les opérations de déplacement sont 
générées uniquement si elles sont nécessaires et, lorsque c’est le cas, elles réalisent des 
« déplacements de niveau membre » sur les données membres non statiques de la classe. 
Autrement dit, le constructeur de déplacement construit par déplacement chaque 
donnée membre non statique de la classe à partir du membre correspondant dans son 
paramètre rhs, et l’opérateur d’affectation par déplacement effectue une affectation 
par déplacement pour chaque donnée membre non statique de son paramètre. Le 
constructeur de déplacement et l’opérateur d’affectation par déplacement traitent 
également les éventuels éléments de la classe de base. 

Lorsque nous parlons d’opération de déplacement, de construction par déplace- 
ment ou d’affectation par déplacement d’une donnée membre ou d’une classe de base, 
rien ne garantit qu’un déplacement aura réellement lieu. Les « déplacements de niveau 
membre » sont en réalité des « demandes » de déplacement de niveau membre car les 
types qui ne sont pas compatibles avec le déplacement (autrement dit qui n’offrent 
aucune prise en charge particulière pour les opérations de déplacement, par exemple 
la plupart des classes anciennes de C++98) seront « déplacés » par des opérations 
de copie. Le « déplacement » de niveau membre se fait en appliquant std: :move à 
l’objet qui sert de source et le résultat est utilisé pendant la résolution de la surcharge 
de fonction pour déterminer si une copie ou uia déplacement doit être effectué. Le 
conseil 23 revient en détail sur ce processus. Pour le moment, il suffit de retenir qu’un 
déplacement de niveau membre correspond à des opérations de déplacement sur les 
données membres et sur les classes de base qui prennent en charge ces opérations, 
sinon il correspond à des opérations de copie. 

À l’instar des opérations de copie, les opérations de déplacement ne sont pas 
générées si nous les déclarons nous-mêmes. En revanche, les conditions précises de 
leur génération automatique diffèrent légèrement. 

Les deux opérations de copie sont indépendantes : déclarer l’une n’empêche pas 
le compilateur de générer l’autre. Par conséquent, si nous déclarons un constructeur 
de copie sans déclarer d’opérateur d’affectation par copie, puis écrivons du code qui a 
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besoin de l’affectation par copie, le compilateur générera cet opérateur à notre place. 
Il en va de même pour la génération du constructeur de copie. Ce comportement était 
valide en C++98 et le reste en C++1 1. 

En revanche, les deux opérations de déplacement ne sont pas indépendantes. 
Si nous déclarons l’une, le compilateur ne génère pas l’autre. En voici la raison : 
en déclarant, par exemple, un constructeur de déplacement pour notre classe, nous 
indiquons implicitement que l’implémentation de cette opération est différente du 
déplacement de niveau membre par défaut que le compilateur générerait. Si la 
construction par déplacement de niveau membre ne convient pas, il est probable 
que l’affectation par déplacement de niveau membre ne convienne pas non plus. 
C’est pourquoi déclarer un constructeur de déplacement empêche la génération d’un 
opérateur d’affectation par déplacement, et vice versa. 

Par ailleurs, les opérations de déplacement ne seront pas générées si la classe 
déclare explicitement une opération de copie. En effet, déclarer une opération de copie 
(construction ou affectation) indique que la méthode normale de copie d’un objet 
(copie de niveau membre) n’est pas adaptée à la classe et le compilateur suppose donc 
que le déplacement de niveau membre n’est pas adapté aux opérations de déplacement. 

Ce comportement est également valable dans l’autre sens. Déclarer une opération 
de déplacement (construction ou affectation) dans une classe conduit le compilateur 
à désactiver les op érations de copie. (La désactivation se fait en supprimant les 
opérations de copie ; voir le conseil 11.) En effet, si le déplacement de niveau membre 
ne convient pas au déplacement d’un objet, on peut supposer que la copie de niveau 
membre n’est pas la bonne manière de le copier. On pourrait penser que cela remet 
en cause le code C++98, car les conditions sous lesquelles les opérations de copie sont 
activées sont plus contraignantes en C+ + 11 qu’en C++98, mais ce n’est pas le cas. 
Puisque la notion de déplacement d’objet n’existe pas en C++98, un code C++98 ne 
peut pas inclure des opérations de déplacement. Pour qu’une ancienne classe puisse 
offrir des opérations de déplacement déclarées par l’utilisateur, il faut les ajouter pour 
C++1 1 et cela doit se faire conformément aux règles C++1 1 de la génération d’une 
fonction membre spéciale. 

Vous avez peut-être entendu parler de la recommandation dite de la Règle des 
trois. Elle explique que s’il nous faut déclarer un constructeur de copie, un opérateur 
d’affectation par copie ou un destructeur, nous devons déclarer les trois. Elle découle 
d’une observation : si nous avons besoin de modifier le sens d’une opération de copie, 
cela signifie presque toujours que la classe effectue une forme de gestion des ressources. 
Et cela implique presque toujours que (1) quelle que soit la gestion de ressources 
effectuée dans une opération de copie, elle devra probablement être réalisée dans 
l’autre opération de copie, et que (2) le destructeur de la classe doit également 
participer à cette gestion (habituellement libérer la ressource). La ressource gérée 
est souvent la mémoire et c’est pourquoi toutes les classes de la bibliothèque standard 
qui gèrent des zones de mémoire (par exemple les conteneurs STL qui effectuent une 
gestion dynamique de la mémoire) suivent cette Règle des trois : elles déclarent les 
deux opérations de copie et un destructeur. 
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En conséquence de la Règle des trois, la présence d’un destructeur déclaré 
par l’utilisateur indique qu’une copie de niveau membre simple est probablement 
inadaptée aux opérations de copie dans la classe. Cela suggère donc que si une classe 
déclare un destructeur, il est fort probable que les opérations de copie qui seraient 
générées automatiquement n’auraient pas le fonctionnement approprié. Au moment 
de l’adoption de C++98, le sens d’un tel raisonnement n’était pas pleinement apprécié 
et l’existence d’un destructeur déclaré par l’utilisateur n’avait pas d’impact sur la 
volonté des compilateurs à générer des opérations de copie. Cela reste le cas en 
C++1 1, mais uniquement parce que le durcissement des conditions de génération des 
opérations de copie rendrait inopérante une trop grande quantité de code ancien. 

Cependant, les fondements de la Règle des trois restent valides et, en y ajoutant 
le fait que la déclaration d’une opération de copie exclut la génération implicite des 
opérations de déplacement, nous avons les raisons pour que C++1 1 ne génère pas 
des opérations de déplacement lorsque la classe dispose d’un destructeur déclaré par 
l’utilisateur. 

Les opérations de déplacement sont donc générées (si nécessaire) uniquement 
lorsque les trois conditions suivantes sont satisfaites : 

• Aucune opération de copie n’est déclarée dans la classe. 

• Aucune opération de déplacement n’est déclarée dans la classe. 

• Aucun destructeur n’est déclaré dans la classe. 

Il est possible que des règles analogues puissent un jour s’appliquer aux opérations 
de copie, car C+ + 11 a rendu obsolète leur génération automatique lorsque la classe 
déclare des opérations de copie ou un destructeur. Par conséquent, si nous avons 
du code qui dépend de la génération des opérations de copie dans des classes qui 
déclarent un destructeur ou l’une des opérations de copie, nous devons les revoir afin 
de supprimer cette dépendance. En supposant que le comportement des fonctions 
générées par le compilateur soit correct (autrement dit que la copie de niveau membre 
des données membres non statiques de la classe corresponde aux besoins), notre travail 
reste simple en C++1 1. Il suffit d’ajouter « = defaul t » pour l’exprimer explicitement : 


class Widget { 
publ ic: 

~Wi dget ( ) ; 

Widget(const Widget&) = default; 
Widget& 

operator=(const Widget&) = defaul 


// Destructeur déclaré 
// par 1 ’util isateur. 

// Le comportement du constructeur 
// de copie par défaut est OK. 

// Le comportement de l’affectation 
; // par copie par défaut est OK. 
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Cette approche est souvent utile avec les classes de base polymorphes, c’est-à-dire 
celles qui définissent des interfaces de manipulation des objets des classes dérivées. 
Les classes de base polymorphes possèdent généralement un destructeur virtuel, car, 
lorsque ce n’est pas le cas, certaines opérations (par exemple l’utilisation de delete 
ou de typeid sur un objet d’une classe dérivée au travers d’un pointeur ou d’une 
référence sur une classe de base) peuvent conduire à des résultats indéfinis ou erronés. 
À moins qu’une classe n’hérite d’un destructeur qui soit déjà virtuel, la seule manière 
de rendre un destructeur virtuel est de le déclarer de la sorte. L’implémentation par 
défaut sera souvent correcte et appliquer « = default » est une bonne manière de 
l’exprimer. Cependant, un destructeur déclaré par l’utilisateur désactive la génération 
des opérations de déplacement et, si ces opérations doivent être prises en charge, 
« = default » trouve alors une seconde application. La déclaration des opérations 
de déplacement désactive les opérations de copie et, si les possibilités de copie sont 
également souhaitées, une nouvelle utilisation de « = defaul t » résout la question : 


class Base I 
public: 

Virtual -BaseO - default; // Rendre le destructeur virtuel. 

Base(Base&&) = default; // Prise en charge du déplacement. 

Base& operator=(Base&&) = default; 

Base(const Base&) = default; // Prise en charge de la copie. 
Base& operator=(const Base&) = default; 


I; 


En réalité, même si nous avons une classe pour laquelle le compilateur est disposé 
à générer des opérations de copie et de déplacement, et pour laquelle les fonctions 
générées auront le comportement approprié, nous pouvons choisir de les déclarer 
nous-mêmes et d’utiliser « = defaul t » dans leur définition. Cela nous demande plus 
de travail, mais nos intentions sont plus claires et certains bogues subtils peuvent 
être plus faciles à découvrir. Par exemple, supposons que nous ayons une classe qui 
représente une table de chaînes de caractères, c’est-à-dire une structure de données 
qui permet des recherches rapides de chaînes de caractères via un identifiant entier : 


class StringTable { 
publ ic: 

St ri ngT a bl e ( ) 1 ) 


Il Fonctions d'insertion, de suppression, de recherche, 
Il etc., mais pas de copie/déplacement/destructeur. 


pri vate: 

std; :map<int, std::string> values; 
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En supposant que la classe ne déclare aucune opération de copie et de déplacement 
ni de destructeur, le compilateur générera automatiquement ces fonctions si elles sont 
utilisées ; une approche très pratique. 

Mais supposons que nous décidions plus tard que la journalisation de la construc- 
tion et de la destruction par défaut de ces objets serait bien utile. L’ajout de cette 
fonctionnalité est simple : 


class StringTable ( 
publ i c : 

Stri ngTabl e( ) 

I makeLogEntry( "Objet StringTable créé"); 1 // Ajoutée. 


~Stri ngTabl e( ) // Également 

( makeLogEntry( "Objet StringTable détruit''); I // ajoutée. 


// Autres fonctions précédentes. 


pri vate: 

std: :map<int, std::string> values; // Comme précédemment. 


T3 

O 
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Cela semble raisonnable, mais la déclaration d’un destructeur a un effet secondaire 
potentiellement important : elle empêche la génération des opérations de déplace- 
ment. Toutefois, la création des opérations de copie de la classe n’est pas touchée. Le 
code va donc certainement compiler, s’exécuter et passer les tests fonctionnels. Cela 
inclut les tests du déplacement car, même si cette classe n’est plus compatible avec 
le déplacement, les requêtes de déplacement compileront et s’exécuteront. Comme 
nous l’avons indiqué précédemment dans ce conseil, elles déclencheront des copies. 
Autrement dit, le code qui « déplace » des objets StringTable effectue en réalité des 
copies, c’est-à-dire des copies des objets std: :map<int, std: : string) sous-jacents. 
Malheureusement, la copie d’un std : :map<i nt , std : : stri ng> risque d’être beaucoup 
plus lente que son déplacement. Le simple fait d’ajouter un destructeur à la classe 
peut donc mener à un problème de performance significatif ! Si nous définissons 
explicitement les opérations de copie et de déplacement avec « = default », ce 
problème disparaît. 

Maintenant que vous avez enduré toutes nos explications sur les règles qui 
gouvernent les opérations de copie et de déplacement en C++1 1, vous vous demandez 
peut-être quand nous allons enfin nous intéresser aux deux autres fonctions membres 
spéciales, le constructeur par défaut et le destructeur. Nous y voilà, mais uniquement 
par cette phrase, car presque rien n’a changé pour ces fonctions membres : les règles 
de C+ + 1 1 sont quasi identiques à celles de C++98. 

Voici donc les règles qui gouvernent les fonctions membres spéciales en C+ + 1 1 : 

• Constructeur par défaut : les mêmes règles qu’en C++98. Il est généré unique- 
ment si la classe ne contient aucun constructeur déclaré par l’utilisateur. 

• Destructeur : globalement les mêmes règles qu’en C++98, la seule différence 
étant que ces destructeurs sont par défaut noexcept (voir le conseil 14). Comme 
en C++98, il est virtuel uniquement si celui de la classe de base est virtuel. 
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• Constructeur de copie : même comportement à l’exécution qu’en C++98, 
c’est-à-dire construction par copie de niveau membre de données membres non 
statiques. Il est généré uniquement si la classe ne possède pas de constructeur de 
copie déclaré par l’utilisateur. Il est supprimé si la classe déclare une opération de 
déplacement. La génération de cette fonction dans une classe qui dispose d’un 
opérateur d’affectation par copie ou d’un destructeur déclaré par l’utilisateur est 
obsolète. 

• Opérateur d’affectation par copie : même comportement à l’exécution qu’en 
C++98, c’est-à-dire affectation par copie de niveau membre des données 
membres non statiques. Il est généré uniquement si la classe ne possède pas 
d’opérateur d’affectation par copie déclaré par l’utilisateur. Il est supprimé si la 
classe déclare une opération de déplacement. La génération de cette fonction 
dans une classe qui dispose d’un constructeur de copie ou d’un destructeur 
déclaré par l’utilisateur est obsolète. 

• Constructeur de déplacement et opérateur d’affectation par déplacement : 

chacun effectue un déplacement de niveau membre des données membres non 
statiques. Ils sont générés uniquement si la classe ne contient aucune opération 
de copie, opération de déplacement ou destructeur déclaré par l’utilisateur. 

Notez que les règles ne disent rien sur l’existence d’un template de fonction membre 
qui empêcherait le compilateur de générer les fonctions membres spéciales. Supposons 
donc que la classe Wi dget soit déclarée ainsi : 


class Widget I 

templ ate<typename T> 

Widgettconst T& rhs); 

templ ate<typename T> 

WidgetS operator=(const T& rhs); 


// Construire un Widget à partir 
//de n’importe quoi. 

Il Affecter un Widget à partir 
Il de n’importe quoi. 


Le compilateur va alors générer les opérations de copie et de déplacement pour 
Widget (en supposant que les conditions habituelles qui régissent leur génération soient 
satisfaites), même si l’instanciation de ces templates permet d’obtenir la signature du 
constructeur de copie et de l’opérateur d’affectation par copie (c’est le cas lorsque T 
est Wi dget). Selon toute vraisemblance, cela vous apparaîtra comme un cas secondaire 
dont il faut rarement se préoccuper, mais nous le mentionnons pour une bonne raison. 
Le conseil 26 montrera en effet qu’il peut avoir des conséquences importantes. 
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À retenir 

• Les fonctions membres spéciales sont celles que le compilateur peut générer 
de lui-même : constructeur par défaut, destructeur, opérations de copie et 
opérations de déplacement. 

• Les opérations de déplacement sont générées uniquement lorsque la classe ne 
déclare explicitement aucune opération de déplacement, opération de copie et 
destructeur. 

• Le constructeur de copie est généré uniquement lorsque la classe ne déclare 
explicitement aucun constructeur de copie et il est supprimé si une opération 
de déplacement est déclarée. L'opérateur d'affectation par copie est généré 
uniquement lorsque la classe ne déclare explicitement aucun opérateur 
d'affectation par copie et il est supprimé si une opération de déplacement 
est déclarée. La génération des opérations de copie dans une classe qui possède 
un destructeur déclaré explicitement est obsolète. 

• Les templates de fonctions membres n'empêchent jamais la génération des 
fonctions membres spéciales. 
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Les poètes et les auteurs-compositeurs ont un faible pour l’amour. Et parfois pour 
le comptage. Quelquefois les deux. Inspirés par les différents essais sur l’amour et 
le comptage d’Elizabeth Barrett Browning (« Comment t’aimé-je ? Laisse-moi t’en 
compter les façons ») et Paul Simon (« There must be 50 ways to leave jour lover »), 
nous pouvons tenter d’énumérer les raisons du désamour pour le pointeur brut : 

1. Sa déclaration n’indique pas s’il pointe sur un seul objet ou sur un tableau. 

2. Sa déclaration ne précise pas si nous devons détruire l’élément sur lequel il 
pointe lorsque nous n’en avons plus besoin, autrement dit si le pointeur détient 
l’élément pointé. 

3. Si nous déterminons que nous devons détruire l’élément pointé par le pointeur, 
rien ne nous dit comment procéder. Devons-nous utiliser del ete ou employer 
un autre mécanisme de destruction (par exemple une fonction de destruction 
particulière à laquelle le pointeur doit être transmis) ? 

4. Si nous réussissons à savoir que nous devons utiliser del ete, la raison 1 fait qu’il 
peut être impossible de choisir entre la version pour un seul objet (« del ete ») 
et celle pour un tableau (« del ete [] »). En cas d’erreur, le résultat est indéfini. 

5. En supposant que nous soyons certains que le pointeur détient l’élément sur 
lequel il pointe et que nous découvrions comment effectuer la destruction, 
il est difficile d’être sûr que la destruction n’est faite qu’une seule fois dans 
l’ensemble de notre code (y compris dans la gestion des exceptions). Manquer 
une destruction conduit à une fuite de ressource et répéter une destruction 
conduit à un comportement indéfini. 

6. Il n’y a en général aucun moyen de savoir si un pointeur pointe dans le 
vide, c’est-à-dire s’il pointe sur une zone de mémoire qui ne contient plus 
l’objet sur lequel le pointeur est supposé pointer. Les pointeurs « pendouillant » 
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apparaissent lorsque des objets sont détruits alors que des pointeurs continuent 
à pointer dessus. 

Les pointeurs bruts sont certes des outils puissants, mais des années d’expérience 
ont montré que la plus petite inattention risque de se retourner contre leurs prétendus 
maîtres. 

Les pointeurs intelligents sont une manière de résoudre ces problèmes. Il s’agit 
d’enveloppes autour de pointeurs bruts, qui se comportent comme les pointeurs qu’ils 
enveloppent, mais en évitant bon nombre de leurs pièges. Il est donc préférable d’éviter 
les pointeurs bruts et d’adopter les pointeurs intelligents. Ils peuvent remplacer les 
pointeurs bruts dans quasiment tous les cas, en laissant peu de place aux erreurs. 

EnC+ + ll, il existe quatre pointeurs intelligents : std: :auto_ptr, std: : uni que_pt r, 
std: :shared_ptr et std: :weak_ptr. Ils sont tous conçus pour faciliter la gestion des objets 
alloués dynamiquement, autrement dit pour éviter les fuites de ressources en s’assurant que 
les objets sont détruits de la bonne manière au bon moment (y compris lors des exceptions). 

std : : auto_ptr est une relique du C++98. Son objectif était de normaliser ce qui 
est devenu std: :unique_ptr en C++ 11. Pour cela, la sémantique de déplacement 
était nécessaire, mais elle n’existait pas en C++98. Pour contourner ce manque, 
std: :auto_ptr faisait passer ses opérations de copie pour des déplacements. Cela 
conduisait à du code surprenant (la copie d’un std: :auto_ptr le fixait à nul !) et à 
des restrictions d’usage frustrantes (en C++11, il n’était pas possible de stocker des 
std::auto_ptr dans des conteneurs ) . 

std : : unique_ptr assure toutes les fonctions de std: :auto_ptr, et plus encore. 
Il est aussi efficace et opère sans travestir la copie d’un objet. Il est meilleur que 
std: :auto_ptr sur tous les plans. Le seul cas d’utilisation légitime de std: :auto_ptr 
réside dans l’obligation d’avoir un code compatible avec C++98. Dans tous les autres, 
std : : auto_ptr doit être systématiquement remplacé par std : : uni que_ptr. 

Les API des pointeurs intelligents sont extrêmement variées. Seule la construction 
par défaut est commune à l’ensemble d’entre elles. Leur description exhaustive étant 
largement disponible, nous allons plutôt nous focaliser sur ce qui manque dans ces 
présentations, par exemple les cas d’utilisation remarquables, l’analyse des coûts à 
l’exécution, etc. La maîtrise de ces aspects fera la différence entre une utilisation 
simple des pointeurs intelligents et leur utilisation efficace. 


CONSEIL N° 18. UTILISER STD: :UNIQUE_PTR POUR LA 
GESTION D'UNE RESSOURCE À PROPRIÉTÉ EXCLUSIVE 

Lorsque nous souhaitons recourir à un pointeur intelligent, std: :unique_ptr doit 
généralement avoir notre priorité. Nous pouvons supposer que, par défaut, les 
std: :unique_ptr ont une taille identique à celle des pointeurs bruts et que, pour 
la plupart des opérations, y compris le déréférencement, ils exécutent exactement 
les mêmes instructions. Nous pouvons donc les employer même dans les cas où 
l’occupation de la mémoire et les temps d’exécution revêtent une grande importance. 



Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 18. Utiliser std: :unique_ptr pour la gestion d'une ressource à propriété exclusive 



TJ 

O 


© 


Si un pointeur brut est suffisamment petit et rapide pour l’application, alors un 
std : : unique_ptr l’est certainement également. 

std : : uni que_ptr incarne la sémantique de propriété exclusive. Un std : : uni que_ptr 
non nul détient toujours l’élément sur lequel il pointe. Le déplacement d’un 
std: :unique_ptr transfère la propriété depuis le pointeur source vers le pointeur 
destination. (Le pointeur source devient nul.) La copie d’un std: :unique_ptr est 
interdite car elle conduirait à deux std : : uni que_ptr sur la même ressource, chacun 
pensant qu’il la détient (et qu’il peut donc la détruire), std: :unique_ptr est par 
conséquent un type réservé au déplacement. Lors de la destruction, un std : : uni que_ptr 
non nul libère sa ressource. Par défaut, la destruction de la ressource se fait en 
appliquant del ete au pointeur brut qui se trouve dans le std : : uni que_ptr. 

std : : uni que_ptr est souvent employé comme type de retour d’une fonction qui 
fabrique des objets d’une hiérarchie. Supposons que nous ayons une hiérarchie de 
types pour représenter des notions d’investissement (par exemple actions, obligations, 
immobilier, etc.) avec une classe de base nommée Investment (figure 4.1) : 


ciass Investment I ... 1; 

// Action. 

// Obligation. 

// Immobilier. 



ciass Stock: 

public Investment I ... I; 

ciass Bond: 

public Investment I ... 1; 

ciass RealEstate: 
public Investment I ... 1; 


Figure 4.1 — Exemple d'une hiérarchie de types représentant des notions d'investissement. 

Avec une telle hiérarchie, la fonction fabrique alloue généralement un objet 
sur le tas et retourne un pointeur sur cet objet, le code appelant étant responsable 
de la suppression de l’objet lorsqu’il ne lui est plus utile. Cette situation convient 
parfaitement à un std : : unique_ptr, car l’appelant devient responsable de la ressource 
retournée par la fabrique (en devient le propriétaire exclusif) et le std: :unique_ptr 
supprime automatiquement l’élément sur lequel il pointe lorsqu’il est détruit. Voici 
comment déclarer la fonction fabrique pour la hiérarchie Investment : 

templ ate<typename. . . Ts> // Retourner un std: :unique_ptr 

std: :unique_ptr<Investment> // sur un objet créé à partir 

makeInvestment(Ts&&. . . params); // des arguments transmis. 
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Dans le code appelant, le std: : uni que_pt r obtenu peut être employé dans une 
même portée : 

I 


auto plnvestment = // plnvestment est de type 

makelnvestment! arguments ); Il std: :unique_ptr<Investment>. 


I II Détruire *plnvestment. 

II peut également être utilisé dans des scénarios de transfert de la propriété. Par 
exemple, le std: :unique_ptr retourné par la fabrique peut être déplacé dans un 
conteneur, puis l’élément du conteneur est déplacé dans une donnée membre d’un 
objet, et cet objet est ensuite détruit. Lorsque cela se produit, la donnée membre 
std: :unique_ptr de l’objet est également détruite, ce qui déclenche la libération 
de la ressource renvoyée par la fabrique. Si la chaîne de propriété est interrompue 
en raison d’une exception ou d’un autre flux de contrôle inhabituel (par exemple 
le retour précoce d’une fonction ou un break dans une boucle), le destructeur du 
std: :unique_ptr qui détient la ressource gérée finira par être invoqué 1 , avec pour 
conséquence la destruction de cette ressource. 

Par défaut, cette destruction se fait avec del ete, mais, au cours de sa construction, 
un objet std: :unique_ptr peut être configuré de façon à utiliser des supprimeurs 
personnalisés ( custom deleters ) : fonctions arbitraires (ou objets fonctions, y compris 
ceux provenant d’expressions lambda) qui sont invoquées lorsque leurs ressources 
doivent être supprimées. Si l’objet créé par makelnvestment ne doit pas être supprimé 
directement avec del ete mais doit commencer par ajouter une entrée dans un journal, 
makelnvestment peut être implémentée de la manière suivante. (Si quelque chose 


vous choque, ne vous inquiétez pas, les explications suivent le code.) 

auto dellnvmt = []( Investirent* plnvestment) 

II 

Supprimeur 

1 

II 

personnal i sé 

makeLogEntry(pInvestment) ; 

II 

(une expression 

delete plnvestment: 

1: 

II 

lambda) . 

template<typename. . . Ts> 

II 

Type de retour 

std: :unique_ptr<Investment, decltypeldel Invmt)> 

II 

revu. 

makeInvestment(Ts&&. . . params) 

1 



i 

std: :unique_ptr<Investment, decl type( del I nvmt ) > 

II 

Pointeur à 

plnv(nullptr, dellnvmt): 

II 

retourner. 


1 . Il existe quelques exceptions à cette règle, la plupart étant liées à une terminaison anormale du 
programme. Si une exception se propage en dehors de la fonction principale d'un thread (par exemple 

mai n pour le thread initial du programme) ou si une spécification noexcept n’est pas respectée (voir 
le conseil 14 ), les objets locaux pourraient ne pas être détruits, et si std : : abort ou une fonction de 
sortie (c’est-à-dire std: :_Exit, std: :exit ou std: :quick_exit) est appelée, ils ne le seront pas. 
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if ( /* Si un objet Stock doit être créé. */ ) 

I 

plnv. reset (new Stock (std : :forward<Ts>(params) ...)); 

1 

else if ( /* Si un objet Bond doit être créé. */ ) 

I 

plnv. reset (new Bond (std: :forward<Ts>(params) . . . ) ) ; 

1 

else if ( /* Si un objet RealEstate doit être créé. */ ) 

I 

plnv. reset (new Real Es ta te (std: : forwardCTsXparams) ...)); 


return plnv; 


-o 

O 
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Nous détaillerons le fonctionnement de ce code plus loin, mais commençons par 
étudier ce qui se passe du côté de l’appelant. En supposant que nous stockions le 
résultat de l’appel à makelnvestment dans une variable auto, nous vivons comme 
des bienheureux sans nous soucier du fait que la ressource exploitée nécessite un 
traitement particulier au moment de la suppression. En réalité, nous pouvons faire 
preuve d’insouciance car l’utilisation de std: : uni que_pt r nous permet d’éviter les 
tracas de la destruction de la ressource (à quel moment la détruire et comment être sûr 
qu’elle ne se produit une seule fois dans l’ensemble du programme), std : : uni que_ptr 
prend automatiquement en charge tous ces aspects. Du point de vue du client, 
l’interface de makelnvestment est agréable. 

L’implémentation est également sympathique, dès lors que l’on comprend les points 
suivants : 

• del Invmt est le supprimeur personnalisé de l’objet renvoyé par makelnvestment. 
Toutes les fonctions de suppression personnalisées prennent un pointeur brut sur 
l’objet à détruire, puis elles s’arrangent pour détruire cet objet. Dans ce cas, la 
procédure consiste à appeler makeLogEntry, puis à appliquer del ete. La création 
de del Invmt avec une expression lambda se révèle pratique mais, nous le verrons 
plus loin, cette solution est également plus efficace que l’écriture d’une fonction 
classique. 

• Lorsqu’un supprimeur personnalisé est requis, son type doit être indiqué dans 
le second argument de type de std : : unique_ptr. Dans notre exemple, il s’agit 
du type de del Invmt et c’est pourquoi le type de retour de makelnvestment 
est std: :unique_ptr<Investment, decltype(del Invmt)>. (Pour de plus amples 
informations sur decl type, consulter le conseil 3.) 

• La stratégie de base de makelnvestment consiste à créer un std: :unique_ptr 
nul, à le faire pointer sur un objet du type approprié, puis à le retourner. Pour 
associer le supprimeur personnalisé del Invmt à plnv, nous le passons en second 
argument du constructeur. 

• L’affectation d’un pointeur brut (par exemple obtenu avec new) à un 
std: :unique_ptr ne passera pas la compilation, car elle représente une 
conversion implicite depuis un pointeur brut vers un pointeur intelligent. 
Puisque de telles conversions implicites peuvent poser des problèmes, les 
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pointeurs intelligents de C++ 11 les interdisent. Nous employons donc reset 
pour que plnv assume la propriété de l’objet créé via new. 

• Pour chaque appel à new, nous utilisons std: :forward de façon à transmettre 
parfaitement les arguments passés à makelnvestment (voir le conseil 25). De 
cette manière, toutes les informations fournies par les appelants sont disponibles 
dans les constructeurs des objets créés. 

• Le supprimeur personnalisé prend un paramètre de type Investiront*. Quel que 
soit le type réel de l’objet créé dans makelnvestment (c’est-à-dire Stock, Bond 
ou Real Estate), il finira par être détruit en tant qu’objet Investment* par un 
appel à del ete dans l’expression lambda. Cela signifie que nous allons détruire 
un objet d’une classe dérivée au travers d’un pointeur sur la classe de base. Pour 
que cela fonctionne, la classe de base, Investment, doit disposer d’un destructeur 
virtuel. 


class Investirent { 
public: 

Virtual ~Investment( ) ; 

I: 


// Élément 

// essentiel 

// de la conception ! 


Grâce à la déduction du type de retour d’une fonction en C+ + 14 (voir le conseil 3), 
nous pouvons avoir une implémentation de makelnvestment plus simple, avec une 
meilleure encapsulation : 


template<typename. . . Ts> 

auto makeInvestment(Ts&&. . . params) 

{ 

auto dellnvmt = []( Investment* plnvestment) 

I 

makeLogEntry( plnvestment) ; 
delete plnvestment: 

I: 


// C++14 . 

// Ce code se trouve 
// à présent dans 
// makelnvestment. 


std: :unique_ptr<Investment, decl type(del Invmt)> // Comme précédemment, 
plnvlnullptr, dellnvmt): 

if ( ... ) // Comme précédemment. 

( 

plnv. reset (new Stock(std: :forward<Ts>( params) . . . ) ) : 

I 

else if ( ... ) // Comme précédemment. 

( 

plnv. reset (new Bond (std: : forward<Ts>( params ) . . . ) ) : 

I 

else if ( ... ) // Comme précédemment. 

( 

plnv. reset (new Real Estate (std: :forward<Ts>( params) ...)); 


return plnv: 


// Comme précédemment. 
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Nous avons indiqué précédemment qu’en utilisant le supprimeur par défaut (c’est-à- 
dire del ete), nous pouvons raisonnablement supposer que les objets std : : uni que_ptr 
ont la même taille que les pointeurs bruts. En présence de supprimeurs personnalisés, 
ce n’est généralement plus le cas. Un supprimeur donné sous forme d’un pointeur 
de fonction augmente la taille d’un std: :unique_ptr d’un ou deux mots. Lorsque 
le supprimeur est un objet fonction, la variation de la taille dépend des éléments 
d’état stockés dans l’objet fonction. Les objets fonctions sans état (par exemple 
provenant d’expressions lambda sans capture) n’ont aucune incidence sur la taille. Par 
conséquent, lorsque l’implémentation d’un supprimeur personnalisé peut se faire sous 
forme soit d’une fonction, soit d’une expression lambda sans capture, cette dernière 
option est préférable : 


auto dellnvmtl = []( Investirent* plnvestment) 

1 

makeLogEntry(pInvestment) ; 
delete plnvestment; 


// Supprimeur 
// personnalisé 
// sous forme 
II à’ expression lambda 
Il sans état. 


templ ate<typename. . . Ts> 

std: :unique_ptr<Investment, decl type (del Invmtl)> 
makeInvestment(Ts&&. . . args); 


Il Le type de retour 
// a la taille de 
Il Investment*. 


void del Invmt2( Investment* plnvestment) 
( 

makeLogEntry(pInvestment) ; 
delete plnvestment; 


Il Supprimeur 
Il personnalisé 
Il sous forme 
Il de fonction. 


templ atektypename. . . Ts> 
std: :unique_ptr<Investment, 

void (*)(Investment*)> 
makeInvestment(Ts&&. . . params); 


Il Le type de retour a la 
Il taille de Investment*, 

Il plus au moins la taille 
Il d’un pointeur de fonction ! 


-o 
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Lorsque des objets fonctions possèdent un état important et sont utilisés comme 
supprimeurs, la taille des objets std: :unique_ptr risque d’être significative. Si un 
supprimeur personnalisé conduit à un std : : unique_ptr trop volumineux, il est 
préférable de revoir la conception du code. 

Les fonctions fabriques ne représentent pas le seul cas d’utilisation classique des 
std : : uni que_ptr. Ils sont même plus connus comme mécanisme d’implémentation de 
l’idiome Pimpl. Le code correspondant n’est pas compliqué, mais il peut parfois ne pas 
être très évident. Nous y reviendrons au conseil 22, consacré à ce sujet. 

Un std: :unique_ptr existe sous deux formes : l’une pour les objets individuels 
(std: :unique_ptr<T>), l’autre pour les tableaux (std: :unique_ptr<T[]>). En consé- 
quence, il n’y a jamais d’ambiguïté sur le type d’entité ciblée par un std: : uni que_ptr. 
L’API de std : : uni que_ptr est conçue pour correspondre à la variante employée. Par 
exemple, il n’existe pas d’opérateur d’indexation (opéra tor [ ] ) dans la forme adaptée 
aux objets individuels, tandis que celle réservée aux tableaux ne dispose pas des 
opérateurs de déréférencement (operator*etoperator->). 
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L’existence de std: :unique_ptr pour les tableaux ne présente essentiellement 
qu’un intérêt intellectuel car std: :array, std: :vector et std: :string sont en général 
des structures de données mieux adaptées aux tableaux bruts. Le seul cas où nous 
pouvons imaginer l’utilisation d’un std: :unique_ptr<T[]> serait dans le contexte 
d’une API de type C qui retourne un pointeur brut sur un tableau alloué sur le tas et 
dont nous devons assurer la propriété. 

std : : uni que_ptr est la manière C++11 d’exprimer une propriété exclusive. Mais 
l’une de ses fonctionnalités les plus attrayantes est qu’il se transforme facilement en 
un std : : shared_ptr efficace : 


I std: :shared_ptr<Investment> sp = // Convertir un std: :unique_ptr 

makelnvestment( arguments ); //en un std: :shared_ptr. 

C’est l’une des principales raisons pour lesquelles un std: :unique_ptr convient 
parfaitement en type de retour d’une fonction fabrique. En effet, ces fonctions ne 
savent pas si le code appelant souhaite une propriété exclusive ou partagée (c’est-à-dire 
un std: :shared_ptr) sur l’objet retourné. En retournant un std: :unique_ptr, elles 
donnent donc aux appelants le pointeur intelligent le plus efficace, sans les empêcher 
de le remplacer par son homologue plus souple. (Pour de plus amples informations sur 
std: :shared_ptr, consulter le conseil 19.) 


À retenir 

• Un std: :unique_ptr est un pointeur intelligent concis, rapide et réservé au 
déplacement. Il convient à la gestion de ressources à propriété exclusive. 

• Par défaut, la destruction d'une ressource se fait avec del ete, mais il est possible 
de spécifier des supprimeurs ( deleters ) personnalisés. Les supprimeurs avec état 
et les pointeurs de fonctions utilisés comme supprimeurs augmentent la taille 
des objets std: :unique_ptr. 

• Convertir un std: :unique_ptr en un std: :shared_ptr est un jeu d'enfant. 


CONSEIL N° 19. UTILISER STD: :SHARED_PTR POUR LA 
GESTION D'UNE RESSOURCE À PROPRIÉTÉ PARTAGÉE 

Les programmeurs qui utilisent des langages dotés d’un ramasse-miettes rigolent bien 
devant le travail que doivent effectuer les programmeurs C++ pour éviter les fuites de 
ressources. « Que ce langage est primitif !», raillent-ils. « N’avez-vous pas lu l’article 
sur Lisp dans les années 1960 1 La vie des ressources doit être gérée non pas par 
les humains mais par les machines. » Les développeurs C++ écarquillent les yeux. 
« Vous voulez parler de l’article dans lequel la seule ressource mentionnée était la 
mémoire et où la libération des ressources était non déterministe ? Merci bien, nous 
préférons le caractère plus général et prévisible des destructeurs. » Notre bravade 
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est en réalité une fanfaronnade. Le ramasse-miettes est réellement très commode et 
la gestion manuelle du cycle de vie des ressources équivaut à construire un circuit 
de mémoire mnémonique à l’aide de couteaux en pierre en étant habillés d’une 
peau d’ours. Pourquoi ne pourrions-nous pas profiter du meilleur des deux mondes : 
un système qui opère de façon automatique (comme le ramasse-miettes), mais qui 
s’applique à toutes les ressources et de manière prévisible (comme les destructeurs) ? 

Pour réunir ces deux mondes, la solution C+ + 11 passe par std : : shared_ptr. 
Lorsqu’un objet est manipulé au travers de std : : shared_ptr, la gestion de son cycle 
de vie est assurée par ces pointeurs, avec une propriété partagée. L’objet n’est détenu 
par aucun std : : shared_ptr en particulier. À la place, tous les std: :shared_ptr 
qui pointent sur cet objet collaborent pour assurer sa destruction lorsqu’il n’est 
plus utile. Lorsque le dernier std : : shared_ptr qui pointe sur un objet arrête de 
pointer dessus (par exemple en raison de la destruction du std : : shared_ptr ou 
de sa redirection vers un autre objet), ce std: :shared_ptr détruit l’objet concerné. 
Grâce au ramasse-miettes, le code client n’a pas à se préoccuper du cycle de vie des 
objets pointés et, grâce aux destructeurs, le moment de la destruction des objets est 
déterministe. 

Pour savoir qu’il est le dernier à pointer sur une ressource, le std: :shared_ptr 
consulte le compteur de références de cette ressource. Il s’agit d’une valeur associée à la 
ressource et dont l’objectif est de suivre le nombre de std : : sha red_ptr qui pointent 
sur elle. Les constructeurs de std : : shared_ptr incrémentent ce compteur (en général, 
mais voir ci-après), les destructeurs le décrémentent, et les opérateurs d’affectation 
par copie effectuent les deux opérations. (Si spl et sp2 sont des std: :shared_ptr 
sur des objets différents, l’affectation « spl = sp2 : » modifie spl de sorte qu’il pointe 
sur l’objet ciblé par sp2. Le compteur de références de l’objet initialement visé par 
spl est décrémenté, tandis que celui de l’objet pointé par sp2 est incrémenté.) Si un 
std : : sha red_pt r constate un compteur de références égal à zéro après avoir effectué 
sa décrémentation, cela signifie que plus aucun std : : shared_ptr ne cible la ressource 
et ce std : : shared_ptr la détruit donc. 

L’existence du compteur de références a un impact sur les performances : 

• La taille des std : : shared_ptr est deux fois plus importante que celle des 
pointeurs bruts car, en interne, ils contiennent un pointeur brut sur la ressource 
et un pointeur brut sur le compteur de références associé à cette ressource 1 . 

• La mémoire associée au compteur de références doit être allouée dynami- 
quement. Conceptuellement, le compteur de références est associé à l’objet 
pointé, mais cet objet n’en a pas connaissance. Il ne dispose donc d’aucune 
place pour stocker un compteur de références. (Conséquence intéressante, cela 
signifie que n’importe quel objet, même un type intégré, peut être géré par un 
std : : shared_ptr.) Le conseil 21 explique que le coût de l’allocation dynamique 
est évité lorsque le std : : shared_ptr est créé par std : :make_shared, mais cette 


1. Cette implémentation n’est pas imposée par la norme, mais c’est elle que nous avons rencontrée 
© partout. 



Copyright © 2016 Dunod. 



Chapitre 4. Pointeurs intelligents 


approche n’est pas toujours envisageable. Quoi qu’il en soit, le compteur de 
références est stocké sous forme de données allouées dynamiquement. 

• Les incrémentations et les décrémentations du compteur de références 
doivent être atomiques. En effet, il est possible que des lectures et des écritures 
se produisent simultanément dans des threads différents. Par exemple, un 
std: :shared_ptr qui pointe sur une ressource dans un thread pourrait être 
en train d’exécuter son destructeur (d’où une décrémentation du compteur 
de références associé à la ressource ciblée), pendant que, dans un thread 
différent, un std : : shared_ptr sur le même objet pourrait être copié (d’où 
une incrémentation du même compteur de références). Puisque les opérations 
atomiques sont typiquement plus lentes que les opérations non atomiques, nous 
pouvons supposer que, même si les compteurs de références n’occupent en 
général qu’un mot, leur lecture et leur écriture sont plus coûteuses. 

Avons-nous piqué votre curiosité en indiquant que les constructeurs de 
std: :shared_ptr incrémentent « en général » le compteur de références de l’objet 
pointé ? Puisque la création d’un std: :shared_ptr qui pointe sur un objet amène 
toujours un std: :shared_ptr supplémentaire à pointer sur cet objet, pourquoi le 
compteur de références n’est-il pas toujours incrémenté ? 

L’explication tient dans la construction par déplacement. En construisant 
un std : : shared_ptr par déplacement à partir d’un autre std: :shared_ptr, le 
std : : shared_ptr d’origine est fixé à nul et ne cible donc plus sa ressource lorsque le 
nouveau std: :shared_ptr entre en scène. Par conséquent, le compteur de références 
ne doit pas être modifié. Le déplacement d’un std : : sha red_ptr est donc plus rapide 
que sa copie, qui exige une incrémentation du compteur de références. Cela est 
également vrai pour l’affectation. Par conséquent, la construction et l’affectation par 
déplacement sont plus rapides que la construction et l’affectation par copie. 

À l’instar de std: :unique_ptr (voir le conseil 18 ), std: :shared_ptr utilise par 
défaut del ete pour la destruction de la ressource, mais il prend également en charge 
les supprimeurs personnalisés. La conception de cette prise en charge diffère toutefois 
de celle de std: :unique_ptr. En effet, dans le cas de std: :unique_ptr, le type du 
supprimeur fait partie du type du pointeur intelligent, ce qui n’est pas le cas pour 
std: :shared_ptr : 


auto loggingDel = [ ] ( Wi dget *pw) // Supprimeur personnalisé 

{ // (comme au conseil 18 ). 

makeLogEntry(pw) ; 


delete pw; 


std: :unique_ptr< 

Widget, decltypedoggingDel ) 

> upw(new Widget, loggingDel); 

std: :shared_ptr<Widget> 
spwtnew Widget, loggingDel); 


// Le type du supprimeur fait 
// partie du type du pointeur. 


// Le type du supprimeur ne fait 
// pas partie du type du pointeur. 
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La conception de std: :shared_ptr est plus souple. Prenons deux 
std : : shared_ptr<Wi dget>, chacun avec un supprimeur personnalisé de type différent 
(par exemple parce que les supprimeurs personnalisés sont spécifiés via des expressions 
lambda) : 


-o 

n 
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auto customDel eterl = [KWidget *pw) { ... I; Il Supprimeurs 

auto customDel eter2 = [ ] ( Wi dget *pw) I ... I: Il personnalisés, chacun 

Il de type différent. 

std: :shared_ptr<Widget> pwl(new Widget, customDeleterl) ; 

std: :shared_ptr<Widget> pw2(new Widget, customDel eter2) ; 

Puisque pwl et pw2 sont du même type, ils peuvent être placés dans un conteneur 
d’objets de ce type : 

std: : vector<std: :shared_ptr<Widget>> vpw( pwl, pw2 |; 

Ils peuvent également être affectés l’un à l’autre et être chacun transmis à une 
fonction qui prend un paramètre de type std : : shared_ptr<Wi dget>. Aucune de ces 
opérations n’est possible avec des std : : unique_ptr qui auraient des supprimeurs 
personnalisés de types différents, car le type du supprimeur personnalisé affecte le type 
du std: :unique_ptr. 

Il existe une différence entre std: :unique_ptr et std : : shared_ptr. La spécification 
d’un supprimeur personnalisé ne change pas la taille d’un objet std : : shared_ptr. Quel 
que soit le supprimeur, la taille d’un objet std : : shared_ptr est celle de deux pointeurs. 
C’est une bonne nouvelle, mais elle vous met peut-être mal à l’aise. En effet, les 
supprimeurs personnalisés peuvent être des objets fonctions, qui peuvent contenir une 
quantité de données quelconque. Autrement dit, ils peuvent avoir une taille arbitraire. 
Comment un std : : sha red_ptr qui fait référence à un supprimeur de taille arbitraire 
fait-il pour ne pas occuper un espace mémoire de taille supérieure ? 

C’est impossible. Il doit utiliser une plus grande quantité de mémoire. Toutefois, 
cette mémoire ne fait pas partie de l’objet std : : shared_ptr. Elle se trouve sur le tas 
ou, si le créateur du std: :shared_ptr tire profit des allocateurs personnalisés, là où 
est placée la mémoire gérée par l’ai locateur. Nous avons mentionné précédemment 
qu’un objet std: : shared_ptr comprend un pointeur sur le compteur de références de 
l’objet ciblé. C’est vrai, mais un tantinet erroné, car le compteur de références fait 
partie d’une structure de données plus large appelée bloc de contrôle. Il existe un bloc 
de contrôle pour chaque objet géré par des std: :shared_ptr. Ce bloc de contrôle 
comprend, outre le compteur de références, une copie du supprimeur personnalisé, 
s’il a été spécifié. Si un allocateur personnalisé a été défini, le bloc de contrôle en 
comprend également une copie. Des données supplémentaires peuvent compléter ces 
informations, par exemple, comme l’explique le conseil 21, un compteur de références 
secondaire, appelé compteur de références faibles, mais nous allons les ignorer dans ce 
conseil. La figure 4.2 montre comment nous pouvons voir la mémoire associée à un 
objet std: : shared_ptr<T>. 
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std: :shared_ptr<T> 



Figure 4.2 — Mémoire associée à un objet std : : shared_ptr<T>. 


Le bloc de contrôle d’un objet est mis en place par la fonction qui crée le premier 
std : : shared_ptr sur l’objet. Tout au moins, c’est ainsi que cela est supposé se passer. 
Malheureusement, la fonction qui crée un std: :shared_ptr sur un objet ne peut 
en général pas savoir si d’autres std: :shared_ptr pointent déjà sur cet objet. Par 
conséquent, voici les règles de la création du bloc de contrôle : 

• std : :make_shared (voir le conseil 21) crée toujours un bloc de contrôle. 
Puisqu’elle fabrique un nouvel objet pointé, il ne devrait donc pas exister de 
bloc de contrôle pour cet objet au moment où elle est appelée. 

• Un bloc de contrôle est créé lorsqu’un std : : shared_ptr est construit à partir 
d’un pointeur à propriété exclusive (c’est-à-dire un std: :unique_ptr ou un 
std: :auto_ptr). Puisque les pointeurs à propriété exclusive ne se servent pas 
des blocs de contrôle, il ne devrait donc pas exister de bloc de contrôle pour 
l’objet pointé. (Pendant sa construction, le std : : sha red_ptr assume la propriété 
de l’objet pointé et le pointeur à propriété exclusive est donc fixé à nul.) 

• Lorsqu’un constructeur de std: : shared_ptr est appelé avec un pointeur 
brut, il crée un bloc de contrôle. Si nous voulions créer un std : : s ha red_pt r à 
partir d’un objet pour lequel il existe déjà un bloc de contrôle, nous passerions 
non pas un pointeur bruit mais certainement un std: : shared_ptr ou un 
std: :weak_ptr (voir le conseil 20) en argument du constructeur. Les construc- 
teurs de std : : shared_ptr qui prennent en arguments des std : : shared_ptr 
ou des std: :weak_ptr ne créent pas de nouveaux blocs de contrôle, car ils 
peuvent compter sur les pointeurs intelligents transmis pour disposer des blocs 
de contrôle requis. 

Ces règles ont une conséquence malheureuse. La construction de plusieurs 
std : : shared_ptr à partir d’un même pointeur brut conduit à un comportement 
indéfini, car plusieurs blocs de contrôle seront associés à l’objet pointé. Ces multiples 
blocs de contrôle signifient plusieurs compteurs de références, ce qui signifie plusieurs 
destructions de l’objet (une pour chaque compteur). Autrement dit, le code suivant 
est on ne peut plus mauvais : 
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auto pw = new Widget; 


// pw est un pointeur brut. 


std: :shared_ptr<Widget> spwl(pw, loggingDel); 


// Bloc de contrôle 
// créé pour *pw. 


std: :shared_ptr<Widget> spw2(pw, loggingDel); 


// 2e bloc de contrôle 
// créé pour *pw ! 


La création du pointeur brut pw sur un objet alloué dynamiquement est une 
mauvaise idée. En effet, elle va à l’encontre du conseil prodigué tout au long de ce 
chapitre : préférer les pointeurs intelligents aux pointeurs bruts. (Si vous avez oublié 
ce qui motive cette préférence, revenez au début de ce chapitre.) Mais laissons cela de 
côté. La ligne qui crée pw est une abomination stylistique, mais au moins elle ne cause 
pas le comportement indéfini du programme. 

Le constructeur de spwl est appelé avec un pointeur brut et crée donc un bloc 
de contrôle (et par conséquent un compteur de références) pour l’élément pointé. 
Dans ce cas, il s’agit de *pw (c’est-à-dire l’objet pointé par pw). Cela ne pose pas de 
problème en soi, mais le constructeur de spw2 est appelé avec le même pointeur brut, 
ce qui conduit à la création d’un bloc de contrôle (et par conséquent d’un compteur 
de références) pour *pw. Il existe donc deux compteurs de références pour *pw. Chacun 
finira par être égal à zéro, ce qui déclenchera deux tentatives de destruction de *pw. 
La seconde est responsable du comportement indéfini. 

Nous pouvons tirer au moins deux leçons de cet exemple d’utilisation de 
std : : sharecLptr. Premièrement, il faut éviter de passer un pointeur brut à un 
constructeur de s td : : shared_ptr. L ’alternative consiste généralement à utiliser 
std : :make_shared (voir le conseil 21 ), mais notre exemple précédent met en œuvre 
des supprimeurs personnalisés, ce qui est incompatible avec std : :make_shared. 
Deuxièmement, si nous devons transmettre un pointeur brut à un constructeur de 
std: :shared_ptr, il faut que ce soit directement le résultat de new, sans passer par 
l’intermédiaire d’une variable. Nous pouvons ainsi réécrire la première partie du code 
précédent : 


I std::shared_ptr<Widget> spwKnew Widget, // Utilisation directe 

loggingDel ) ; //de new. 


Nous serons alors moins tentés de créer un second std: :shared_ptr à partir du 
même pointeur brut. À la place, il semblera plus naturel de créer spw2 en passant 
spwl en argument d’initialisation (autrement dit appeler le constructeur de copie de 
std: : shared_ptr), ce qui évitera tout problème : 


I std: : sha red_ptr<Wi dget> spw2(spwl); // spw2 se sert du même bloc 

// de contrôle que spwl. 
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Une autre utilisation particulièrement surprenante d’un pointeur brut en argument 
du constructeur de std : : shared_ptr menant à la création de plusieurs blocs de 
contrôle implique le pointeur thi s. Supposons que notre programme fonde la gestion 
d’objets Wi dget sur des std : : shared_ptr et que la trace des Wi dget traités est conservée 
dans une structure de données : 

std: :vector<std: :shared_ptr<Widget>> processedWidgets; 

Supposons également que le traitement soit réalisé par une fonction membre de 

Wi dget : 

class Widget { 
publ ic: 

void processO; 


Voici une façon a priori convenable d’implémenter Wi dget : : process : 
void Widget: :process( ) 


Il Traiter le Widget. 

processedWidgets. emplace_back(this) ; Il L’ajouter à la liste 

I II des Widget traités ; 

Il mauvaise idée ! 

Le commentaire indique que la façon de procéder est mauvaise. (Le problème 
concerne le passage de thi s, non l’utilisation de empl ace_back. Pour de plus amples 
informations sur empl ace_back, consulter le conseil 42.) La compilation de ce code 
ne pose aucune difficulté, mais il transmet un pointeur brut (thi s) à un conteneur 
de std: :shared_ptr. Le std: :shared_ptr ainsi construit va créer un nouveau bloc 
de contrôle pour le Wi dget pointé (*thi s). Cela n’a rien de choquant, jusqu’à ce que 
nous réalisions que si des std : : shared_ptr extérieurs à la fonction membre pointent 
déjà sur ce Wi dget, le comportement indéfini décrit précédemment est de retour. 

L’API std: :shared_ptr apporte une solution à cette situation. Son nom est 
probablement le plus bizarre de tous ceux de la bibliothèque C++ standard : 
std : : ena bl e_shared_f rom_thi s. Il s’agit d’un template pour une classe de base dont 
nous devons hériter pour qu’une classe gérée par des std : : shared_ptr puisse créer en 
toute sécurité un std : : shared_ptr à partir d’un pointeur thi s. Voici son utilisation 
dans notre exemple de Wi dget : 

class Widget: public std: :enable_shared_from_this<Widget> ( 

publ ic: 

void processO: 
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Nous l’avons dit, std: :enabl e_shared_f rom_thi s est un template de classe de 
base. Son paramètre de type est toujours le nom de la classe dérivée. Par conséquent, 
Wi dget hérite donc de std: : enabl e_shared_f rom_thi s<Wi dget>. Si l’idée d’une classe 
dérivée qui hérite d’un template d’une classe de base sur la classe dérivée vous donne 
le tournis, essayez de ne pas trop y penser. Le code est parfaitement valide et le design 
pattern sur lequel il se fonde est parfaitement connu. Son nom est établi, même s’il 
est aussi étrange que std: : enabl e_shared_f rom_thi s : Curiously Recurring Template 
Pattern (CRTP). Si vous souhaitez en apprendre plus sur ce pattern, toumez-vous vers 
votre moteur de recherche car nous devons revenir à std : : enabl e_shared_f rom_thi s. 

std: :enable_shared_from_this définit une fonction membre qui crée un 
std : : sha red_pt r sur l’objet courant, mais sans dupliquer les blocs de contrôle. Cette 
fonction se nomme shared_f rom_thi s et nous devons l’appeler depuis les fonctions 
membres pour obtenir un std : : shared_ptr qui cible le même objet que le pointeur 
thi s. Voici une implémentation fiable de Widget : : process : 

void Widget: :process( ) 

I 

// Comme précédemment, traiter le Widget. 

// Ajouter le std: :shared_ptr sur l’objet courant 

// à processedWidgets . 

processedWidgets.empl ace_back(shared_f rom_this( ) ) ; 

I 

De façon interne, shared_from_thi s recherche le bloc de contrôle associé à l’objet 
courant et crée un nouveau std : : s ha red_pt r qui fait référence à ce bloc de contrôle. 
Ce comportement suppose qu’un bloc de contrôle soit associé à l’objet courant. Pour 
cela, il doit déjà exister un std : : shared_ptr (par exemple en dehors de la fonction 
membre qui appelle shared_f rom_thi s) qui pointe sur l’objet courant. Si ce n’est 
pas le cas (autrement dit si aucun bloc de contrôle n’est lié à l’objet courant), le 
comportement est indéfini, mais shared_f rom_thi s lance en général une exception. 

Pour éviter que du code client n’appelle des fonctions membres qui invoquent 
shared_f rom_thi s avant qu’un std: :shared_ptr ne pointe sur l’objet, les classes qui 
dérivent de std : : enabl e_shared_f rom_thi s déclarent souvent leurs constructeurs 
priva te et permettent la création des objets au travers de fonctions fabriques qui 
retournent des std: :shared_ptr. Par exemple, Widget pourrait être déclarée de la 
manière suivante : 

class Widget: public std: : enabl e_shared_from_this<Widget> { 

publ ic: 

// Fonction fabrique qui transmet parfaitement les arguments 

// à un constructeur privé. 

templ ate<typename. . . Ts> 

static std: :shared_ptr<Widget> create(Ts&&. . . params); 

void processO; 


// Comme précédemment. 
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pri vate: 


Il Constructeurs. 


À ce stade, vous avez peut-être vaguement oublié que nos propos sur les blocs 
de contrôle étaient motivés par une volonté de comprendre les coûts associés aux 
std : : sharecLptr. Puisque nous savons à présent comment éviter la création d’un trop 
grand nombre de blocs de contrôle, revenons au sujet initial. 

La taille d’un bloc de contrôle est en général de quelques mots, bien que les 
supprimeurs et les allocateurs personnalisés puissent l’augmenter. L’implémentation 
classique d’un bloc de contrôle est donc plus sophistiquée qu’on l’aurait imaginé. 
L’héritage et une fonction virtuelle sont de la partie. (La fonction virtuelle est utilisée 
pour s’assurer que la destruction de l’objet pointé se fait correctement.) Autrement 
dit, l’utilisation des std: :shared_ptr subit également le coût de toute la mécanique 
associée à la fonction virtuelle employée par le bloc de contrôle. 

Nous avons donc des blocs de contrôle alloués dynamiquement, des supprimeurs 
et des allocateurs de taille arbitraire, la mécanique des fonctions virtuelles et les 
manipulations atomiques d’un compteur de références. Nous pourrions comprendre 
que votre enthousiasme pour les std : : shared_ptr ait quelque peu disparu. Certes, ils 
n’apportent pas la meilleure solution à chaque problème de gestion d’une ressource, 
mais ils ont un coût très raisonnable. Dans des conditions classiques, lorsque le 
supprimeur et l’allocateur par défaut sont employés et lorsque le std: :shared_ptr 
est créé avec std : :make_shared, le bloc de contrôle occupe simplement trois mots et 
son allocation est quasiment gratuite. (Elle est incluse dans l’allocation de la mémoire 
destinée à l’objet pointé ; voir le conseil 21.) Déréférencer un std : : shared_ptr n’est 
pas plus coûteux que déréférencer un pointeur brut. Effectuer une opération qui 
demande la manipulation d’un compteur de références (par exemple, une construction 
ou une affectation par copie, une destruction) entraîne une ou deux opérations 
atomiques, mais celles-ci correspondent généralement à des instructions machine 
en propre, qui ne seront pas nécessairement plus coûteuses que des instructions non 
atomiques (ce sont des instructions simples). La mécanique des fonctions virtuelles 
dans le bloc de contrôle est généralement activée une seule fois pour chaque objet 
géré via des std : : shared_ptr : au moment où l’objet est détruit. 

En échange de ces coûts plutôt modestes, nous obtenons une gestion automatique 
du cycle de vie des ressources allouées dynamiquement. La plupart du temps, l’emploi 
d’un std: :shared_ptr est beaucoup plus intéressant que la gestion manuelle d’un 
objet dont la propriété est partagée. En cas de doute sur l’intérêt de l’utilisation 
d’un std: :shared_ptr, il faut réfléchir à la nécessité d’une propriété partagée. Si 
une propriété exclusive fait ou pourrait faire l’affaire, std : : uni que_ptr représente un 
meilleur choix. Ses performances sont proches de celles obtenues avec des pointeurs 
bruts et le passage de std : : unique_ptr à std : : shared_ptr reste facile, car nous 
pouvons créer un std: :shared_ptr à partir d’un std: :unique_ptr. 

L’inverse est faux. Dès lors que la gestion d’une ressource a été confiée à un 
std : : shared_ptr, il n’est plus possible de revenir en arrière. Même si le compteur de 
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références reste à un, nous ne pouvons pas réclamer la propriété de la ressource, par 
exemple pour la gérer à l’aide d’un std: :unique_ptr. Le contrat de propriété entre 
une ressource et les std: : shared_ptr qui pointent dessus est signé « jusqu’à ce que la 
mort nous sépare ». 

Par ailleurs, les std : : shared_ptr sont incompatibles avec les tableaux. Au 
contraire de std : : unique_ptr, std : : shared_ptr dispose d’une API conçue 
uniquement pour des pointeurs sur des objets, std : : s h a red_p t r <T [ ]> n’existe 
pas. De temps à autre, des programmeurs « astucieux » se mettent en tête 
d’utiliser un std: : shared_ptr<T> pour pointer sur un tableau, en définissant un 
supprimeur personnalisé pour la destruction du tableau (c’est-à-dire delete []). Il 
est possible que leur code compile, mais l’idée est très mauvaise. Tout d’abord, 
puisque std: :shared_ptr ne propose pas operator[], l’indexation dans le tableau 
exige des expressions délicates à base d’arithmétique sur les pointeurs. Ensuite, 
std: : shared_ptr prend en charge les conversions de pointeurs entre classe de base et 
classe dérivée qui ont un sens pour les objets simples, mais qui ouvrent des brèches 
dans le système de typage lorsque les tableaux sont concernés. (C’est pour cette raison 
que l’APl de std: :unique_ptr<T[]> interdit ces conversions.) Mais plus important 
encore, en raison de la diversité des méthodes de création d’un tableau en C+ + 11 
(par exemple std::array, std::vector, std : : st ri ng), la déclaration d’un pointeur 
intelligent sur un tableau de base est toujours signe d’une mauvaise conception. 


A retenir 

• Les std : : shared_ptr ont une utilité proche de celle d'un ramasse-miettes pour 
la gestion du cycle de vie de ressources quelconques partagées. 

• En comparaison de std: :unique_ptr, les objets std: :shared_ptr ont une taille 
généralement deux fois plus importante, impliquent un surcoût lié aux blocs de 
contrôle et exigent des manipulations atomiques du compteur de références. 

• La destruction de la ressource se fait par défaut avec del ete, mais les supprimeurs 
personnalisés sont pris en charge. Le type du supprimeur n'a pas d'incidence 
sur celui du std: :shared_ptr. 

• Il faut éviter de créer des std: :shared_ptr à partir de variables de type pointeur 
brut. 


CONSEIL N° 20. UTILISER STD: : WEAK_PTR 
POUR DES POINTEURS DE TYPE STD: :SHARED_PTR 
QUI PEUVENT PENDOUILLER 
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Cela pourrait paraître paradoxal, mais il peut être comm ode d’avoir un poi nteur 
intelligent qui opère à la manière d’un std: :shared_ptr (voir le conseil 19) sans 
qu’il participe au partage de la propriété de la ressource pointée. Autrement dit, un 
pointeur du type de std: :shared_ptr qui n’affecte pas le compteur de références 
d’un objet. Cette forme de pointeur intelligent doit affronter un problème inconnu 
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des std : : sharecLptr : la possibilité de pointer sur un élément qui a été détruit. Un 
pointeur véritablement intelligent traitera cette question en détectant le moment 
où il pendouille (pointe dans le vide), c’est-à-dire lorsque l’objet sur lequel il est 
supposé pointer n’existe plus. C’est précisément le type de pointeur mis en œuvre par 
std: :weak_ptr. 

Vous vous demandez peut-être à quoi peut bien servir std: :weak_ptr. Votre 
interrogation sera même plus grande encore si vous examinez l’API de std : :weak_ptr. 
Elle a l’air de tout, sauf intelligent. Les std : :weak_ptr ne peuvent pas être déréférencés, 
ni comparés à nul. En effet, un std: :weak_ptr n’est pas un pointeur intelligent 
autonome, mais une extension de std: :shared_ptr. 

Les liens sont établis dès la naissance. Les std: :weak_ptr sont en général créés 
à partir de std : : shared_ptr. Ils pointent sur les mêmes emplacements que les 
std : : sha red_ptr ayant servi à leur initialisation, mais ils n’affectent pas le compteur 
de références de l’objet ciblé : 


auto spw = 

std: :make_shared<Widget>( ) ; 


std: :weak_ptr<Widget> wpw(spw); 


spw = nul lptr; 


// Après la construction de spw, 
// le compteur de références du 
// Widget pointé est ég al à 1. 

// (Voir le conseil 21 pour des 
// infos sur std: :make_shared . ) 


// wpw pointe sur le même Widget 
// que spw. Le compteur reste à 1. 


// Le compteur passe à 0 
// et le Widget est détruit. 
// wpw pendouille à présent. 


Les std: :weak_ptr qui pointent dans le vide sont dits périmés. Il est possible de 
tester directement cet état : 


I if (wpw. expi red( ) ) ... Il Si wpw ne pointe pas 

Il sur un objet- 

Mais nous souhaitons le plus souvent vérifier si un std: :weak_ptr est périmé 
et, dans la négative (autrement dit, s’il ne pendouille pas), accéder à l’objet pointé. 
C’est plus facile à souhaiter qu’à réaliser. Puisque les std: :weak_ptr ne peuvent pas 
être déréférencés, il n’est pas possible d’écrire ce code. Et même s’ils disposaient 
de cet opérateur, la séparation du contrôle et du déréférencement introduirait une 
condition de concurrence : entre l’appel à expi red et le déréférencement, un autre 
thread pourrait réaffecter ou détruire le dernier std : : shared_ptr qui pointe sur l’objet, 
provoquant ainsi la destruction de celui-ci. Le déréférencement mènerait alors à un 
comportement indéfini. 

Nous avons donc besoin d’une opération atomique qui vérifie si le std: :weak_ptr 
est périmé et, dans le cas contraire, nous donne accès à l’objet pointé. Pour cela, nous 
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créons un std: :shared_ptr à partir du std: :weak_ptr. Cette opération existe sous 
deux formes, dont le choix dépend du comportement souhaité si le std : :weak_ptr est 
périmé lorsque nous l’utilisons pour créer un std : : s ha red_ptr. La première variante 
est std: :weak_ptr: :lock,qui retourne un std: : shared_ptr. Ce std: :shared_ptr est 
nul si le std: :weak_ptr est périmé : 

std: :shared_ptr<Widget> spwl = wpw.lockO; // Si wpw est périmé, 

// spwl est nul . 

auto spw2 = wpw.lockO: // Comme ci-dessus, 

// mais avec auto. 

La seconde variante est apportée par le constructeur de std : : sha red_ptr qui prend 
un std: :weak_ptr en argument. Dans ce cas, si le std: :weak_ptr est périmé, une 
exception est levée : 

std: : shared_ptr<Widget> spw3(wpw); // Si wpw est périmé, 

// lancer std: :bad_weak_ptr . 

Mais tout cela n’explique pas l’utilité des std: :weak_ptr. Examinons une fonc- 
tion fabrique qui produit des pointeurs intelligents sur des objets en lecture seule 
à partir d’un identifiant unique. Conformément au conseil 18, elle retourne un 

std: : unique_ptr : 

std: :unique_ptr<const W i d g e t > 1 oadWidget(WidgetID id); 

Si 1 oadWi dget est une opération coûteuse (par exemple elle effectue des entrées- 
sorties sur un fichier ou une base de données) et si les identifiants sont souvent utilisés 
de façon répétée, une optimisation normale serait d’écrire une fonction qui réalise le 
traitement de 1 oadWi dget et place ses résultats dans un cache. Cependant, encombrer 
le cache avec chaque Wi dget qui aura été demandé risque de poser des problèmes de 
performances. Une optimisation raisonnable serait donc de détruire les W i dget du 
cache lorsqu’ils ne sont plus utilisés. 

Pour cette fonction fabrique avec cache, le type de retour std: :unique_ptr ne 
convient pas. Le code appelant doit effectivement recevoir des pointeurs intelligents 
sur les objets mis dans le cache et il doit fixer le cycle de vie de ces objets, mais le 
cache a également besoin d’un pointeur sur les objets. Les pointeurs du cache doivent 
être en mesure de détecter lorsqu’ils pendouillent. En effet, lorsque les clients de 
la fabrique n’ont plus besoin d’un objet qu’elle a retourné, celui-ci doit être détruit. 
L’entrée correspondante dans le cache pointe alors dans le vide. Les pointeurs mis dans 
le cache doivent donc être des std : :weak_ptr, c’est-à-dire des pointeurs qui détectent 
s’ils pendouillent. Cela signifie que la fabrique doit retourner un std: :shared_ptr, car 
les std: :weak_ptr ne peuvent détecter cet état que si la vie d’un objet est gérée par 
des std: :shared_ptr. 

Voici une implémentation rapide de 1 oadWi dget avec la gestion d’un cache : 
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std: :shared_ptr<const Wi dget > fastLoadWidget(WidgetID id) 

( 

static std: :unordered_map<WidgetID, 

std: :weak_ptr<const Widget>> cache; 


auto objPtr = cache[id] . 1 ock( ) ; 


if (! objPtr) I 
objPtr = 1 oadWi dget ( i d ) ; 
cachefid] = objPtr; 

I 

return objPtr; 


// objPtr est un std: :shared_ptr 
// sur un objet en cache (ou nul 
// si l’objet ne s’y trouve pas). 

// Si absent du cache, 

// le charger, 

// le mettre en cache. 


Cette version se fonde sur une table de hachage de C++11 (std: : unordered_map), 
même si elle ne montre pas les fonctions de hachage et de comparaison d’égalité de 
WidgetlD qui sont requises. 

L’implémentation de fastLoadWidget ignore le fait que le cache puisse avoir 
accumulé des std: :weak_ptr périmés qui correspondent à des Widget qui ne sont 
plus utilisés (et qui ont donc été détruits). La mise en oeuvre peut être améliorée, 
mais au lieu de passer du temps sur un problème qui n’apporte aucune information 
supplémentaire sur les std: :weak_ptr, intéressons-nous à un second cas d’utilisation : 
le design pattern Observateur. Les principaux composants de ce pattern sont les 
observables (objets qui peuvent changer d’état) et les observateurs (objets avertis d’un 
changement d’état). Dans la plupart des implémentations, chaque observable contient 
une donnée membre qui mémorise des pointeurs sur ses observateurs. La génération des 
notifications de changement d’état est ainsi aisée. Les observables n’ont aucun intérêt 
à contrôler le cycle de vie de leurs observateurs (c’est-à-dire lorsqu’ils sont détruits), 
mais ils ont tout intérêt à s’assurer que si un observateur est détruit, ils ne tentent 
plus d’y accéder. Nous pouvons alors concevoir chaque observable en lui attribuant 
un conteneur de std: :weak_ptr sur ses observateurs, pour qu’il puisse déterminer si 
un pointeur pendouille avant de l’utiliser. 

Examinons un dernier exemple de l’utilité des std : :weak_ptr. Prenons une 
structure de données qui contient des objets A, B et C, et où A et C partagent la propriété 
de B et possèdent donc des std: :shared_ptr sur cet objet (figure 4.3). 



std: :shared_ptr std: :shared_ptr 


Figure 4.3 — Partage d'un objet via des std: :shared_ptr 
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Supposons que nous ayons également besoin d’un pointeur de B vers A. Quelle 
forme de pointeur doit-on choisir (figure 4 4) ? 
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Figure 4.4 — Quel type de pointeur de retour pour éviter les cycles ? 

Nous avons trois possibilités : 

• Un pointeur brut. Dans cette approche, si A est détruit et si C continue à pointer 
sur B, le pointeur de B sur A pendouillera. B ne pourra pas détecter ce fait et 
risque de déréférencer par inadvertance un pointeur dans le vide. Cela mènera 
à un comportement indéfini. 

• Un std : : shared_ptr. Avec cette conception, A et B contiennent des pointeurs 
std: :shared_ptr sur chacun d’eux. Le cycle de std: :shared_ptr résultant (A 
pointe sur B et B pointe sur A) empêche la destruction de A et de B. Même si 
A et B ne peuvent plus être atteints à partir des autres structures de données 
du programme (par exemple parce que C ne pointe plus sur B), chacun aura 
un compteur de références égal à un. Dans ce cas, A et B sont à l’origine d’une 
fuite de ressources : le programme ne peut plus y accéder et leurs ressources ne 
peuvent pas être libérées. 

• Un std : :weak_ptr. Cette solution évite les deux problèmes précédents. Si A est 
détruit, le pointeur de B sur A pendouille, mais B est capable de le détecter. Par 
ailleurs, même si A et B pointent l’un sur l’autre, le pointeur de B n’affecte pas 
le compteur de références de A, et A peut donc être détruit lorsque plus aucun 
std: :shared_ptr ne pointe dessus. 

Les std: :weak_ptr constituent manifestement le meilleur choix. Toutefois, nous 
devons préciser que la nécessité d’employer des std: :weak_ptr pour éviter des cycles 
éventuels de std : : shared_ptr est peu courante. Dans les structures de données stricte- 
ment hiérarchiques, comme les arbres, les nœuds enfants sont généralement détenus 
uniquement par leurs parents. Lorsqu’un nœud parent est détruit, ses nœuds enfants 
doivent l’être également. Les std : : uni que_ptr conviennent donc à la représentation 
des liens depuis les parents vers les enfants. Les liens de retour des enfants vers les 
parents peuvent être mis en œuvre avec des pointeurs bruts, car un nœud enfant ne 
doit pas avoir une durée de vie plus longue que celle de son parent. Il n’y a donc aucun 
risque qu’un nœud enfant ne déréférence un pointeur dans le vide sur son parent. 

Toutes les structures de données à base de pointeurs ne sont évidemment pas 
strictement hiérarchiques et, lorsque ce n’est le cas, ainsi que dans d’autres situations 
comme celles du cache et de la liste des observateurs, il est bon de savoir que les 
std: :weak_ptr sont prêts à servir. 

Sur le plan de l’efficacité, un std : :weak_ptr équivaut à un std : : shared_ptr. La 
taille des objets std: :weak_ptr est identique à celle des objets std: :shared_ptr, ils 
utilisent les mêmes blocs de contrôle (voir le conseil 19), et les opérations comme 





Copyright © 2016 Dunod. 



Chapitre 4. Pointeurs intelligents 


leur construction, leur destruction et leur affectation imposent des manipulations 
atomiques du compteur de références. Cela vous surprend peut-être, car nous avons 
indiqué au début de ce conseil que les std: :weak_ptr n’interviennent pas dans le 
comptage des références. Mais nous n’avons pas dit exactement cela. Nous avons 
précisé que les std : :weak_ptr ne participaient pas au partage de la propriété des objets 
et qu’ils n’avaient donc pas d’incidence sur le compteur de références de l’objet pointé. 
En réalité, le bloc de contrôle comprend un second compteur de références et c’est 
celui-ci que les std : :weak_ptr manipulent. Le conseil 21 revient en détail sur ce sujet. 


À retenir 

• Utiliser des std: :weak_ptr lorsque des pointeurs de type std: :shared_ptr 
peuvent pendouiller. 

• Les cas d'utilisation des std: :weak_ptr comprennent notamment la mise en 
cache, les listes d'observateurs et la prévention de cycle de std: :shared_ptr. 


CONSEIL N° 21. PRÉFÉRER STD: : MAKE_UN I QU E 

ET STD: :MAKE_SHARED À UNE UTILISATION DIRECTE DE NEW 

Commençons par établir les terrains de jeu de std : :make_uni que et de 
std: :make_shared. std : :make_shared fait partie de C++11, contrairement à 
std: :make_unique. Il a rejoint la bibliothèque standard avec C++ 14. Si vous utilisez 
C++ 1 1 , ne paniquez pas car l’écriture d’une version basique de std: :make_unique n’a 
rien de complexe. La voici : 

templ ate<typename T, typename... Ts> 

std: :unique_ptr<T> make_unique(Ts&&. . . params) 

I 

return std: :imique_ptr<T>(new T C std : :forward<Ts>(paratns) . . . ) ) : 


Vous le constatez, make_uni que se contente de relayer parfaitement ses paramètres 
au constructeur de l’objet à créer, construit un std : : uni que_ptr à partir du pointeur 
brut obtenu de new, et renvoie ce std : : uni que_ptr créé. Une telle version ne prend pas 
en charge les tableaux ni les supprimeurs personnalisés (voir le conseil 18), mais elle 
montre que, en cas de besoin, peu d’efforts suffisent à écrire une fonction make_uni que 1 . 
Faites attention à ne pas placer votre version dans l’espace de noms std, car elle 
entrerait en conflit avec celle de la bibliothèque standard de C+ + 14 au moment de la 
mise à niveau. 


1. Pour créer une fonction ma ke_un i que qui offre toutes les fonctionnalités, toujours avec le minimum 
d’effort possible, recherchez son implémentation dans le document de normalisation qui la met en 
exergue, puis copiez-la. Ce document rédigé par Stephan T. Lavavej possède le numéro N3656, en 
date du 18 avril 2013. 
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std: :make_unique et std : :make_shared sont deux des trois fonctions mâke : des fonc- 
tions qui prennent un jeu d’arguments quelconque, les retransmettent parfaitement au 
constructeur d’un objet alloué dynamiquement, et retournent un pointeur intelligent 
sur cet objet. La troisième fonction make se nomme std : : al 1 ocate_shared. Elle opère 
comme std : :make_shared, mais son premier argument est un objet d’allocation qui se 
charge de la réservation dynamique de la mémoire. 

Une comparaison simple de la création d’un pointeur intelligent avec et sans passer 
par une fonction make révèle déjà l’intérêt d’une telle fonction : 


-o 
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auto upwKstd: :make_unique<Widget>( ) ) ; Il Avec une fonction make. 
std: :unique_ptr<Widget> upw2(new Widget); Il Sans fonction make. 


auto spwKstd: :make_shared<Widget>( ) ) ; Il Avec une fonction make. 

std: :shared_ptr<Widget> spw2(new Widget): Il Sans fonction make. 


Nous avons mis en exergue la différence principale : les versions fondées sur 
new répètent le type créé, contrairement à celles basées sur les fonctions make. La 
répétition des types va à l’encontre d’un principe essentiel de l’ingénierie logicielle : la 
duplication du code doit être évitée. En effet, elle augmente le temps de compilation, 
produit du code objet lourd et, généralement, rend la manipumation de la base de 
code plus difficile. Elle mène souvent à du code incohérent, et les incohérences dans 
une base de code conduisent souvent à des bogues. Par ailleurs, la saisie en double 
demande plus d’efforts, alors que l’objectif des programmeurs est plutôt de réduire 
cette charge de travail. 

La seconde raison de préférer les fonctions make est en lien avec la sécurité vis-à-vis 
des exceptions. Supposons que nous ayons une fonction qui traite un Widget en 
fonction de la priorité indiquée : 

void processWidget(std: :shared_ptr<Widget> spw, int priority); 


Le passage par valeur du std: :shared_ptr pourrait sembler douteux, mais 
le conseil 41 explique que si processWi dget effectue toujours une copie du 
std: : shared_ptr (par exemple en le stockant dans une structure de données qui sert 
au suivi des Widget traités), ce choix de conception peut être approprié. 

Nous disposons également d’une fonction qui calcule la priorité requise : 


int computePriority( ) ; 

Supposons que nous l’utilisions dans un appel à processWi dget fondé sur new à la 
place de std: :make_shared : 
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I processWidget(std: :shared_ptr<Widget>(new Widget), Il Fuite de 
computePriorityO); Il ressource 

Il potentielle ! 

Comme l’indique le commentaire, ce code peut perdre le Widget produit par 
new. Par quel processus ? En effet, le code appelant et la fonction appelée emploient 
des std: :shared_ptr et les std: :shared_ptr sont conçus pour éviter les fuites 
de ressources. Ils détruisent automatiquement l’élément ciblé lorsque le dernier 
std: :shared_ptr qui pointe dessus disparaît. Puisque tout le monde utilise systémati- 
quement des std: :shared_ptr, d’où vient la fuite ? 

La réponse se trouve dans la manière dont le compilateur convertit le code source 
en code objet. À l’exécution, les arguments d’une fonction doivent être évalués avant 
que celle-ci ne puisse être invoquée. Par conséquent, dans l’appel à processWi dget, 
voici les opérations qui doivent avoir lieu avant que l’exécution de processWi dget ne 
débute : 

• L’expression « new Widget » est évaluée, ce qui déclenche la création d’un 
Widget sur le tas. 

• Le constructeur de std: :shared_ptr<Widget> responsable de la gestion du 
pointeur fourni par new est exécuté. 

• La fonction computePriori ty est exécutée. 

Le compilateur n’est pas obligé de générer un code qui effectue ces opérations 
dans cet ordre. « new Widget » doit se produire avant l’appel au constructeur de 
std: :shared_ptr, car le résultat de new sert d’argument à ce constructeur, mais il 
est possible d’exécuter computePri ori ty avant, après ou, point essentiel, entre ces 
appels. Autrement dit, le code produit par le compilateur peut effectuer des opérations 
dans l’ordre suivant : 

1. Exécuter « new Widget». 

2. Appeler computePri ori ty. 

3. Invoquer le constructeur de std: :shared_ptr. 

Supposons que ce code soit généré et que, pendant l’exécution, computePri ori ty 
lève une exception. Dans ce cas, l’objet Widget alloué dynamiquement à l’étape 1 sera 
perdu, car il ne sera jamais stocké dans le std: :shared_ptr qui est censé le gérer à 
l’étape 3. 

En utilisant std : :make_shared, nous évitons ce problème. Voici le code correspon- 
dant : 

I processWidget(std: :make_shared<Widget>( ) , // Aucune fuite de 

computePriorityO); // ressource. 

À l’exécution, soit std: :make_shared, soit computePri ori ty est appelée en premier. 
S’il s’agit de std: :make_shared, le pointeur brut sur le Widget alloué dynamiquement 
est stocké en toute sécurité dans le std: :shared_ptr renvoyé avant que compute- 
Pri ori ty ne soit appelée. Dans le cas où computePri ori ty lance une exception, le 
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destructeur de std : : shared_ptr veillera à ce que le Wi dget qu’il détient soit détruit. 
Si computePri ori ty est appelée en premier et lève une exception, std : :make_shared 
ne sera pas invoquée et aucun Wi dget ne sera alloué dynamiquement. 

Si nous remplaçons std: :shared_ptr et std: :make_shared par std: :unique_ptr 
et std : :make_uni que, nous pouvons tenir le même raisonnement. Pour écrire du code 
sûr vis-à-vis des exceptions, il est tout aussi important d’utiliser std : :make_uni que à 
la place de new que d’utiliser std : :make_shared. 

En comparaison d’une utilisation directe de new, std : :make_shared présente 
l’avantage d’améliorer l’efficacité du code. En effet, le compilateur peut générer un 
code plus concis et plus rapide qui se fonde sur des structures de données plus légères. 
Examinons un appel direct à new : 

std: :shared_ptr<Widget> spwtnew Widget); 

Il est évident qu’une allocation de mémoire a lieu, mais, en réalité, ce code en 
effectue deux. Le conseil 19 explique que chaque std : : shared_ptr pointe sur un bloc 
de contrôle qui contient, entre autres, le compteur de références associé à l’objet ciblé. 
La zone de mémoire réservée à ce bloc de contrôle est allouée par le constructeur de 
std : : shared_ptr. Autrement dit, l’utilisation directe de new nécessite une première 
allocation de mémoire pour le Widget et une seconde pour le bloc de contrôle. 

Supposons à présent que nous utilisions std : :make_shared : 

auto spw = std: :make_shared<Widget>( ) ; 

Dans ce cas, une seule allocation suffit. En effet, std: :make_shared alloue une 
seule zone de mémoire qui contiendra l’objet Widget et le bloc de contrôle. Cette 
optimisation réduit la taille statique du programme, car le code comprend un seul appel 
à l’allocation de la mémoire, et elle augmente sa vitesse d’exécution, car l’allocation 
est effectuée une seule fois. Par ailleurs, en utilisant std: :make_shared, certaines 
informations de gestion ne sont plus nécessaires dans le bloc de contrôle et l’empreinte 
mémoire globale du programme s’en trouve donc potentiellement diminuée. 

Puisque ce constat d’efficacité de std: :make_shared concerne également 
std : : al 1 ocate_sha red, cette fonction permet aussi d’améliorer les performances. 

Nous avons donc toutes les raisons de préférer les fonctions make à une utilisation 
directe de new. Toutefois, malgré leurs avantages sur le plan de l’ingénierie logicielle, 
de la sécurité vis-à-vis des exceptions et de l’efficacité, ce conseil préconise de préférer 
les fonctions make, non de les utiliser systématiquement. Il existe en effet des situations 
où elles ne peuvent pas ou ne doivent pas être employées. 

Par exemple, aucune des fonctions make ne permet de spécifier des supprimeurs 
personnalisés (voir les conseils 18 et 19), mais std : : unique_ptr et std: :shared_ptr 
offrent des constructeurs qui les prennent en charge. Supposons le supprimeur 
personnalisé suivant pour un Wi dget : 

auto widgetDeleter = [](Widget* pw) I ... ); 
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Avec new, il est très facile de créer un pointeur intelligent qui l’utilise : 

std: :unique_ptr<Widget, decl type ( widget Del e ter )> 

upw(new Widget, widgetDeleter) ; 

std: :shared_ptr<Widget> spw(new Widget, widgetDeleter): 

Avec une fonction make, cette possibilité n’existe pas. 

Une seconde restriction des fonctions make provient d’un détail syntaxique dans 
leur implémentation. Le conseil 7 explique que lors de la création d’un objet dont le 
type surcharge des constructeurs avec et sans des paramètres std : : i ni ti al izer_l i st, 
la création avec des accolades choisit le constructeur avec std : : i ni ti al i zer_l i st, 
tandis que la création avec des parenthèses se fonde sur le constructeur sans 
std : : i ni ti al i zer_l i st. Les fonctions make retransmettent parfaitement leurs 
paramètres au constructeur de l’objet, mais emploient-elles pour cela des parenthèses 
ou des accolades ? Selon les types des arguments, la réponse à cette question fera une 
grande différence. Prenons par exemple les appels suivants : 

auto upv = std: :make_unique<std: : vector<int>>(10, 20); 

auto spv = std: :make_shared<std : :vector<int»(10, 20): 

Les pointeurs intelligents obtenus pointent-ils sur des std : : vector de 10 éléments, 
chacun ayant la valeur 20, ou sur des std::vectorde2 éléments, l’un ayant la valeur 
10, l’autre, la valeur 20 ? Ou, le résultat est-il indéterminé ? 

Bonne nouvelle, le résultat n’est pas indéterminé : les deux appels créent des 
std: : vector de 10 éléments, tous fixés à la valeur 20. Cela signifie que le code de 
retransmission parfaite dans les fonctions make utilise non pas des accolades mais des 
parenthèses. Mauvaise nouvelle : si nous voulons construire l’objet pointé en utilisant 
un initialiseur à accolades, nous devons appeler directement new. Pour employer 
une fonction make, il faudrait pouvoir retransmettre parfaitement un initialiseur à 
accolades, mais, comme l’explique le conseil 30, ce n’est pas possible avec ce type 
d’initialiseur. Le conseil 30 propose toutefois une alternative : exploiter la déduction 
de type au to pour créer un objet std : : i ni ti al i zer_l i st à partir d’un initialiseur à 
accolades (voir le conseil 2), puis passer l’objet créé par auto au travers de la fonction 
make : 

// Créer un std: : initial izer_l ist. 

auto i ni t Li st = { 10, 20 } ; 

// Créer un std::vector en utilisant le constructeur de 

// std: :i ni ti al izer_l ist. 

auto spv = std: :make_shared<std: :vector<int>XinitList) ; 

Pour std : : unique_ptr, voilà les deux seuls scénarios (supprimeurs personnalisés et 
initialiseurs à accolades) dans lesquels ces fonctions make posent des difficultés. Pour 
std: :shared_ptr et ces fonctions make, il existe deux cas supplémentaires, qui sont 
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peut-être limites, mais certains développeurs prennent des risques et vous pourriez en 
faire partie. 

Certaines classes définissent leur propre version de operator new et de operator 
del ete. L’existence de ces fonctions sous-entend que les routines globales d’allocation 
et de désallocation de la mémoire ne sont pas adaptées aux objets de ce type. Le plus 
souvent, les routines spécifiques à une classe sont conçues uniquement pour allouer 
et désallouer des zones de mémoire dont la taille correspond précisément à celle des 
objets de la classe. Par exemple, les fonctions operator new et operator del ete de 
la classe Widget sont faites uniquement pour allouer et désallouer des morceaux de 
mémoire dont la taille est égale à s izeof( Widget). Ces routines s’accordent mal à la 
prise en charge de l’allocation ( via std : : al 1 ocate_shared) et de la désallocation ( via 
des supprimeurs personnalisés) personnalisées de std: :shared_ptr, car la quantité 
de mémoire demandée par std: :al locate_shared ne correspond pas à la taille de 
l’objet alloué dynamiquement, mais à cette taille plus celle d’un bloc de contrôle. Par 
conséquent, utiliser des fonctions make pour créer des objets dont la classe dispose de 
versions spécifiques de operator new et de operator del ete est souvent une mauvaise 
idée. 

Les avantages en termes de taille et de rapidité de std: :make_shared par rapport 
à une utilisation directe de new proviennent du placement du bloc de contrôle 
std : : shared_ptr dans la même zone de mémoire que l’objet géré. Lorsque son 
compteur de références atteint zéro, l’objet est détruit (son destructeur est appelé). 
Cependant, la mémoire qu’il occupe ne peut pas être libérée tant que le bloc de 
contrôle n’a pas également été détruit, car elle contient ces deux éléments. 

Le bloc de contrôle ne contient pas uniquement le compteur de références mais 
également d’autres informations de gestion. Le compteur de références permet le suivi 
du nombre de std: :shared_ptr qui font référence au bloc de contrôle, mais celui-ci 
contient un second compteur qui dénombre les std : : wea k_ptr qui font référence au 
bloc de contrôle. Ce second compteur de référe nces est appelé le compteur faible 1 . 
Lorsqu’un std: :weak_ptr vérifie s’il est périmé (voir le conseil 19), il examine le 
compteur de références (non le compteur faible) dans le bloc de contrôle associé. Si 
ce compteur est à zéro (autrement dit si plus aucun std: :shared_ptr ne pointe sur 
l’objet, qui a donc été détruit), cela signifie que le std : :weak_ptr est périmé. 

Tant que des std : :weak_ptr font référence à un bloc de contrôle (c’est-à-dire que 
le compteur faible est supérieur à zéro), celui-ci doit continuer à exister. Et, tant qu’un 
bloc de contrôle existe, la mémoire qui le contient doit rester allouée. La zone de 
mémoire allouée par la fonction std : : shared_ptr make ne peut donc pas être libérée 
tant que le dernier std: :shared_ptr et le dernier std: :weak_ptr qui y font référence 
n’ont pas été détruits. 


1. Dans la pratique, la valeur du compteur faible n’est pas toujours égale au nombre de std : : wea k_ptr 
qui font référence au bloc de contrôle, car les développeurs de bibliothèques ont trouvé des manières 
de glisser des informations supplémentaires dans ce compteur de façon à obtenir du code plus efficace. 
Dans le cadre de cette section, nous ignorons cela et supposons que la valeur du compteur faible 
© correspond au nombre de std : :weak_ptr qui font référence au bloc de contrôle. 
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Si la taille du type de l’objet est assez importante et si le temps entre la destruction 
du dernier std: :shared_ptr et du dernier std: :weak_ptr est relativement long, un 
décalage peut se produire entre le moment où l’objet est détruit et celui où la mémoire 
qu’il occupait est libérée : 


class ReallyBigType ( ... I; 

auto pBigObj = // Créer un très grand 

std: :make_shared<ReallyBigType>( ) ; // objet par le biais 

// de std: :make_shared . 

// Créer des std: :shared_ptr et des std: :weak_ptr sur 
// l’objet volumineux et les utiliser pour le manipuler. 

// Le dernier std: :shared_ptr sur l’objet est détruit ici, 

// mais il reste des std: :weak_ptr. 

Il Au cours de cette période, la mémoire initialement 
Il occupée par l’objet volumineux reste allouée. 

Il Le dernier std: :weak_ptr sur l’objet est détruit ici ; 

Il la mémoire pour le bloc de contrôle et l’objet est libérée. 


En utilisant directement new, la mémoire réservée à l’objet ReallyBigType peut 
être libérée dès que le dernier std : : shared_ptr associé à l’objet est détruit : 


class ReallyBigType { ... (; // Comme précédemment. 

std: :shared_ptr<Real 1 y B i gTy pe> pBigObj(new ReallyBigType): 

// Créer un très grand 
// objet avec new. 

// Comme précédemment, créer des std: :shared_ptr et 
// des std: :weak_ptr sur l’objet et les utiliser. 

// Le dernier std: :shared_ptr sur l’objet est détruit ici, 
// mais il reste des std: :weak_ptr : 

II la mémoire réservée à l’objet est désal louée. 

Il Au cours de cette période, seule la mémoire réservée 
Il au bloc de contrôle reste allouée. 

Il Le dernier std: :weak_ptr sur l’objet est détruit ici ; 
Il la mémoire pour le bloc de contrôle est libérée. 


Si nous nous trouvons dans une situation où l’utilisation de std: :make_shared est 
impossible ou inappropriée, nous voudrons néanmoins éviter les problèmes de sécurité 
vis-à-vis des exceptions décrits précédemment. Pour cela, la meilleure solution consiste 
à passer immédiatement le résultat de l’utilisation directe de new au constructeur d’un 
pointeur intelligent dans une instruction qui ne fait rien d’autre. De cette manière, 
le compilateur ne générera pas du code qui pourrait lancer une exception entre 
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l’utilisation de new et l’invocation du constructeur du pointeur intelligent en charge 
de l’objet alloué par new. 

Prenons comme exemple une version légèrement modifiée de l’appel à la fonction 
processWi dget qui n’était pas sûre vis-à-vis des exceptions. Cette fois-ci, nous 
spécifions un supprimeur personnalisé : 


void processWidget(std: :shared_ptr<Widget> spw, 
Int priority); 


// Comme précédemment. 


void cusDel (Widget *ptr); 


// Supprimeur 
// personnalisé. 


Voici l’appel non sûr vis-à-vis des exceptions : 


processWidget( 

std: :shared_ptr<Widget>(new Widget, cusDel), 
computePri ori ty( ) 

): 


// Comme précédemment, 
II fuite de 
Il ressources 
Il potentielle ! 


Petit rappel : si computePri ori ty est appelée après « new Widget » mais avant le 
constructeur de std: :shared_ptr et si computePri ori ty lance une exception, le Widget 
alloué dynamiquement est perdu. 

Puisque l’utilisation d’un supprimeur personnalisé empêche celle de 
std: :make_shared, la manière d’éviter le problème consiste à placer l’allocation du 
Widget et la construction du std: :shared_ptr dans leur propre instruction, puis 
d’appeler processWidget avec le std: :shared_ptr obtenu. Voici les bases de la 
technique, mais, comme nous le verrons plus loin, il est possible d’en améliorer les 
performances : 


std: :shared_ptr<Widget> spw(new Widget, cusDel); 

processWidgetispw, computePriority( ) ) ; // Correct, sans être optimal ; 

// voi r ci -après . 

Cela fonctionne, car un std: :shared_ptr assume la propriété du pointeur brut 
passé à son constructeur, même si celui-ci lève une exception. Dans cet exemple, si 
le constructeur de spw lance une exception (par exemple en raison de l’impossibilité 
d’allouer dynamiquement de la mémoire pour un bloc de contrôle), l’invocation de 
cusDel sur le pointeur fourni par « new Widget » est garantie. 

Le petit souci de performance vient du fait que, dans l’appel non sûr vis-à-vis des 
exceptions, nous passons une rvalue à processWidget : 


processWidget( 

std: :shared_ptr<Widget>(new Widget, cusDel), // L’argument est une 

// rvalue. 

computePri ori ty( ) 

); 
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alors que, dans l’appel sûr vis-à-vis des exceptions, nous passons une lvalue : 


I processWidget(spw, computePriorityC ) ) ; Il L’argument est une 

Il lvalue. 

Puisque le paramètre std: :shared_ptr est passé par valeur à processWidget, la 
construction à partir d’une rvalue demande seulement un déplacement, tandis que 
celle à partir d’une lvalue impose une copie. Pour un std : : sha red_ptr, la différence 
peut être significative, car copier un std : : shared_ptr implique une incrémentation 
atomique de son compteur de références, tandis que le déplacer n’en demande aucune 
manipulation. Pour que le code sûr vis-à-vis des exceptions arrive au même niveau 
de performance que le code non sûr vis-à-vis des exceptions, nou s devons appliquer 
std : :move à spw afin de le convertir en rvalue (voir le conseil 23) : 

I processWidget(std::move(spw), // À la fois efficace et sûr 

computePriori ty( ) ) ; // vis-à-vis des exceptions. 

C’est intéressant et bon à savoir, mais cela reste souvent inapproprié car les raisons 
de ne pas utiliser une fonction make sont plutôt rares. Et, à moins qu’une telle raison 
existe vraiment, il faut utiliser une fonction make. 


À retenir 

• Au contraire de l'utilisation directe de new, les fonctions make éliminent la 
duplication du code source, améliorent la sécurité vis-à-vis des exceptions et, 
pour std: :make_shared et std: :allocate_shared, permettent d'obtenir un code 
plus concis et plus rapide. 

• Les fonctions make ne conviennent pas lorsque des supprimeurs personnalisés 
ou des initialiseurs à accolades sont requis. 

• Pour les std: :shared_ptr, il existe d'autres cas où les fonctions make sont 
inappropriées : (1) classes avec une gestion personnalisée de la mémoire et (2) 
systèmes où l'occupation mémoire importe, où des objets sont très volumineux 
et où des std: :weak_ptr vivent plus longtemps que les std: :shared_ptr 
correspondants. 


CONSEIL N° 22. AVEC L'IDIOME PIMPL, DÉFINIR DES 
FONCTIONS MEMBRES SPÉCIALES DANS LE FICHIER 
D'IMPLÉMENTATION 

Si vous avez déjà eu à résoudre des problèmes de temps de construction excessif, 
l’idiome Pimpl (pointer to implémentation) ne vous est certainement pas inconnu. Cette 
technique consiste à remplacer les données membres d’une classe par un pointeur sur 
une classe (ou une structure) d’implémentation, à placer dans celle-ci les données 
membres qui se trouvaient dans la classe initiale, et à accéder à ces données membres 
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indirectement au travers du pointeur. Supposons, par exemple, que la classe Wi dget 
soit écrite de la manière suivante : 


class Widget { // Dans l’en-tête "widget.h". 

publ i c : 

W i d g e t ( ) ; 

pri vate: 

std : : string name; 

std: :vector<double> data; 

Gadget gl, g2, g3; // Gadget est un type défini 

1 ; // par l 'utilisateur. 


Puisque les données membres de Widget ont les types std : : stri ng, std : : vector 
et Gadget, les en-têtes de ces types doivent être présents pour que la classe Widget 
puisse être compilée. Autrement dit, le code qui utilise Wi dget doit inclure < s t r i ng>, 
<vector>etgadget.h. Ces fichiers d’en-tête augmentent le temps de compilation des 
clients de Wi dget et les rendent dépendants de leur contenu. Si un fichier d’en-tête est 
modifié, les clients de Widget doivent être recompilés. Les en-têtes standard < s t r i ng> 
et <vector> seront rarement modifiés, mais il est possible que gadget . h fasse l’objet de 
révisions fréquentes. 

Pour appliquer l’idiome Pimpl en C++98, nous remplaçons les données membres 
de Wi dget par un pointeur brut sur une structure déclarée mais non définie : 


class Widget { 
publ ic: 

W i d g e t ( ) ; 

—Wi dget ( ) ; 


// Toujours dans l’en-tête ''widget.h”. 
// Destructeur requis (voir ci -après). 


-o 

n 


private: 

struct Impi ; 
Impi *plmpl ; 


Il Déclarer la structure d’implémentation 
Il et le pointeur associé. 


© 


Puisque les types std : : stri ng, std : : vector et Gadget ne sont plus mentionnés dans 
Widget, le code qui utilise cette classe n’a plus besoin d’inclure les fichiers d’en-tête 
pour ces types. La compilation s’en trouve accélérée et, si ces en-têtes sont modifiés, 
les clients de Widget n’en sont pas affectés. 

Un type qui a été déclaré sans avoir été défini est appelé type incomplet. Wid- 
get: : Impi en est un exemple. Les utilisations d’un type incomplet sont peu nom- 
breuses, mais l’une d’elles est de déclarer un pointeur sur ce type. L’idiome Pimpl se 
fonde sur cette possibilité. 

La première partie de l’idiome Pimpl correspond à la déclaration d’une donnée 
membre qui est un pointeur sur un type incomplet. La seconde partie implique 
l’allocation dynamique et la désallocation de l’objet qui contient les données membres 
présentes auparavant dans la classe d’origine. Le code d’allocation et de désallocation 
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va dans le fichier d’implémentation. Par exemple, pour Widget, il s’agit du fichier 

widget.cpp : 


#include "widget. h" // Dans le fichier d’implémentation 

#include "gadget. h" // "widget.cpp". 

#include <string> 

#include <vector> 


struct Widget: : Impi I 
std: : s t r i n g name; 
std: : vector<doubl e> data; 
Gadget gl, g2, g3; 

I: 


// Définition de Widget:: Impi 
// avec les données membres 
// précédemment dans Widget. 


Widget: :Widget( ) // Allouer les données membres 

: plmpKnew Impi) // pour cet objet Widget. 


Widget: : ~Wi dget ( ) // Détruire les données membres 

1 delete plmpl ; I // pour cet objet. 


Nous montrons les directives #include afin que les choses soient claires : les 
dépendances globales avec les en-têtes pour std:: string, std::vector et Gadget 
continuent à exister. Cependant, elles ne sont plus dans wi dget . h (qui est vu et utilisé 
par le code client de Widget) mais dans wi dget . cpp (qui est vu et utilisé uniquement 
par le code d’implémentation de Wi dget). Nous illustrons également le code qui alloue 
dynamiquement et désalloue l’objet Impi . Puisque nous devons désallouer cet objet 
lors de la destruction d’un Wi dget, le destructeur de Widget est indispensable. 

Mais ce code C++98 date d’une époque révolue. Il se fonde sur des pointeurs 
bruts et des appels à new et à delete. Ce chapitre s’articule autour de l’idée que les 
pointeurs intelligents sont meilleurs que les pointeurs bruts, et si nous voulons une 
allocation dynamique d’un objet Wi dget : : Impi dans le constructeur de Wi dget, avec 
sa destruction en même temps que le Wi dget, un std: : uni que_ptr (voir le conseil 18) 
va répondre parfaitement à nos besoins. En remplaçant le pointeur brut plmpl par un 
std : : uni que_ptr, nous obtenons le code d’en-tête suivant : 


class Widget I // Dans "widget. h", 

publ ic: 

Widget! ) ; 


pri vate: 
struct Impi ; 

std: :unique_ptr<Impl> plmpl; // Utiliser un pointeur intelligent 

I; // à la place du pointeur brut. 


Voici le fichier d’implémentation correspondant : 
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#incl ude "widget.h" Il Dans "widget.cpp" . 

#inc1ude "gadget. h" 

#i ncl ude <string> 

#include <vector> 

struct Widget: : Impi { Il Comme précédemment, 

std: :string name; 
std: :vector<double> data; 

Gadget gl, g2, g3; 


Widget: :Widget( ) Il Conformément au conseil 21, 

: pimpl (std: :make_unique<Impl X ) ) Il créer un std: :unique_ptr 
(( Il avec std: :make_unique. 


Vous l’aurez remarqué, le destructeur de Widget a disparu. En effet, nous n’avons 
plus de code à y mettre, std : : uni que_ptr supprime automatiquement l’élément sur 
lequel il pointe lorsqu’il (le std : : uni que_ptr) est détruit. Nous n’avons donc plus rien 
à supprimer par nous-mêmes. Voilà l’un des attraits des pointeurs intelligents : ils nous 
évitent toute implication dans la libération manuelle des ressources. 

Si la compilation de ce code ne pose pas problème, ce n’est pas le cas pour le code 
client le plus simple : 


T3 

O 
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#i ncl ude "widget.h” 

Widget w; // Erreur ! 

Le message d’erreur généré dépend du compilateur, mais il mentionne générale- 
ment l’application de si zeof ou de del ete à un type incomplet. Ces opérations font 
partie des opérations impossibles sur de tels types. 

Cette faillite apparente de l’idiome Pimpl fondé sur les std : : uni que_ptr est alar- 
mante car (1) std : : unique_ptr est censé prendre en charge les types incomplets et (2) 
l’idiome Pimpl est l’un des cas d’utilisation types des std : : unique_ptr. Heureusement, 
la correction du code ne pose aucune difficulté. Il suffit simplement de comprendre 
l’origine du problème. 

Elle se trouve dans le code généré lors de la destruction de w (par exemple, lorsqu’il 
est hors de portée) et que son destructeur est invoqué. Dans la définition de la 
classe qui utilise std : : uni que_ptr, nous n’avons déclaré aucun destructeur car nous 
n’avons aucun code à y placer. En accord avec les règles habituel les des fonctions 
membres spéciales générées par le compilateur (voir le conseil 17), celui-ci génère 
un destructeur à notre place. Il y insère du code qui appelle le destructeur de la 
donnée membre pimpl de Widget. pimpl est un std: : uni que_ptr<Widget : : Impi >, 
c’est-à-dire un std : : uni que_ptr qui utilise le supprimeur par défaut. Celui-ci est une 
fonction qui appelle del ete sur le pointeur brut contenu dans le std: :unique_ptr. 
Cependant, avant d’utiliser del ete, les implémentations du supprimeur par défaut se 
servent généralement de stati c_assert de C+ + 11 pour vérifier que le pointeur brut 
ne vise pas un type incomplet. Lorsque le compilateur génère le code de destruction 
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du Wi dget w, il rencontre généralement un stati c_assert qui échoue et qui conduit 
donc au message d’erreur. Le message est associé à l’emplacement de la destruction de 
w car le destructeur de Wi dget, comme toute fonction membre spéciale générée par le 
compilateur, est implicitement inline. Le message fait souvent référence à la ligne 
où w est créé car c’est le code source qui crée explicitement l’objet qui conduit à sa 
destruction implicite ultérieure. 

Pour corriger le problème, il suffît de s’assurer qu’à l’endroit où le code de 
destruction du std : : unique_ptr<Wi dget : : Impi > est généré, Wi dget : : Impi est un type 
complet. Pour qu’un type soit complet, sa définition doit avoir été rencontrée. Puisque 
Wi dget : : Impi est défini dans wi dget . cpp, nous devons faire en sorte que le compilateur 
voie le corps du destructeur de Wi dget (c’est-à-dire l’endroit où le compilateur générera 
du code pour détruire la donnée membre std: :unique_ptr) uniquement à l’intérieur 
de wi dget. cpp, après la définition de Wi dget: : Impi . 

Pour cela, nous déclarons le destructeur de Widget dans widget.h, mais sans le 
définir dans ce fichier : 

class Widget I // Comme précédemment, dans "widget.h". 

publ ic: 

Wi dget ( ) ; 

-WidgetO; II Déclaration uniquement. 


private: Il Comme précédemment, 

struct Impi ; 

std: : unique_ptr<Impl > plmpl : 


Sa définition arrive dans widget. cpp, après celle de Widget: : Impi : 

#include "widget.h" // Comme précédemment, dans "widget. cpp" . 

#include "gadget. h” 

#include <string> 
f/include <vector> 

struct Widget:: Impi { // Comme précédemment, définition de 

std : : st r i ng name; // Widget: : Impi . 

std: :vector<double> data; 

Gadget gl, g2, g3; 


Widget: : Wi dget ( ) // Comme précédemment. 

: plmpl (std: :make_unique<Impl X ) ) 


Widget: :~Widget( ) // Définition de -Widget. 

I {} 

Cette solution fonctionne parfaitement et nécessite peu de saisie. Mais, si nous 
voulons souligner le fait que le destructeur généré par le compilateur effectue le travail 
approprié et que la seule raison de le déclarer était que sa définition soit générée dans 
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le fichier d’implémentation de Widget, nous pouvons définir le corps du destructeur 
avec « = defaul t » : 

Widget: : ~Wi dget ( ) = default; // Même résultat que précédemment. 

Les classes qui se fondent sur l’idiome Pimpl sont parfaitement adaptées à la 
prise en charge du déplacement car les opérations correspondantes générées par le 
compilateur réalisent exactement ce que nous souhaitons : effectuer un déplacement 
du std: : uni que_pt r sous-jacent. Mais, comme l’explique le conseil 17, la déclaration 
d’un destructeur dans Widget empêche le compilateur de générer les opérations de 
déplacement. Par conséquent, pour prendre en charge le déplacement, nous devons 
déclarer ces fonctions nous-mêmes. Étant donné que les versions générées par le 
compilateur auraient le comportement approprié, nous pourrions être tentés de les 
implémenter de la manière suivante : 


class Widget { 

II 

Toujours dans 

publ ic: 

II 

"widget. h" . 

Widget! ) ; 



-Widget! ) ; 



Widget(Widget&& rhs) = default; 

II 

Bonne idée. 

Widget& operator=(Widget&& rhs) = default; 

II 

mauvais code ! 

private: 

II 

Comme précédemment 


struct Impi ; 

std: :unique_ptr<Impl> pimpl; 


Cette approche conduit à un problème comparable à celui de la déclaration de la 
classe sans destructeur, essentiellement pour la même raison. L’opérateur d’affectation 
par déplacement généré par le compilateur doit détruire l’objet pointé par pimpl avant 
de le réaffecter, mais, dans le fichier d’en-tête de Widget, pimpl point sur un type 
incomplet. Le cas du constructeur de déplacement est différent. Le problème vient du 
fait que le compilateur produit généralement un code pour détruire pimpl dans le cas 
où une exception surviendrait à l’intérieur du constructeur de déplacement, mais la 
destruction de pimpl exige que son type soit complet. 

Puisque le problème est identique au précédent, nous pouvons le corriger de la 
même manière. Nous plaçons la définition des opérations de déplacement dans le 
fichier d’implémentation : 
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class Widget I // Toujours dans "widget. h”, 

publ ic: 

W i d g e t ( ) ; 

~Wi dget ( ) ; 

Widget(Widget&& rhs); II Déclarations 

Widget& operator=(Widget&& rhs); Il uniquement. 
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pri vate: 
struct Impl ; 

std: : unique_ptr<Impl > plmpl ; 


#include <string> 


struct Widget: : Impl ( ... 1 ; 
Widget: : Wi dget ( ) 

: plmpl (std: :make_unique<Impl X ) ) 
11 

Widget: : ~Wi dget ( ) = default; 


// Comme précédemment. 


// Comme précédemment, 
// dans "widget. cpp" . 

// Comme précédemment. 

// Comme précédemment. 

// Comme précédemment. 


Widget: : Wi dget ( Wi dget&& rhs) = default: II Définitions. 

Widget& Widget: :operator=(Widget&& rhs) = default; 


L’idiome Pimpl permet de diminuer les dépendances de compilation entre l’im- 
plémentation d’une classe et les clients de cette classe mais, conceptuellement, son 
utilisation ne change en rien ce qu’elle représente. La classe Wi dget d’origine contenait 
des données membres std: : string, std: :vector et Gadget, et, en supposant que, 
à l’instar des std:: string et des std::vector, les Gadget peuvent être copiés, il 
serait sensé que Wi dget prenne en charge les opérations de copie. Nous devons écrire 
ces fonctions nous-mêmes car (1) le compilateur ne génère pas les opérations de 
copie pour les classes qui comprennent de types réservés aux déplacements, comme 
std : : unique_ptr, et (2), même s’il le faisait, les fonctions générées copieraient 
uniquement le std : : uni que_ptr (effectueraient une copie superficielle), alors que nous 
voulons copier l’élément ciblé par le pointeur (réaliser une copie profonde). 

Selon le rituel désormais familier, nous déclarons les fonctions dans le fichier 
d’en-tête et les mettons en œuvre dans le fichier d’implémentation : 


class Widget I // Toujours dans "widget. h", 

publ ic: 

// Autres fonctions, comme précédemment. 


Widget(const Widget& rhs); II Déclarations 

Widget& operator=(const Widget& rhs): Il uniquement. 

private: Il Comme précédemment, 

struct Impl ; 

std: : unique_ptr<Impl > plmpl; 


#include "widget. h" 


// Comme précédemment, dans "widget. cpp” . 
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struct Widget: : Impi I ... 1; Il Comme précédemment. 

Widget: :~Widget( ) = default; Il Autres fonctions, comme précédemment. 

Widget: :Widget(const WidgetS rhs) Il Constructeur de copie. 

: pimpl (s td: :make_unique<lmpl>(*rhs.plmpl )) 

() 

Widget& Widget: :operator=(const Widget& rhs) Il Opérateur 

Il d’affectation par 
Il copie. 

{ 

*p Impi = *rhs. pimpl ; 
return *this; 

} 


L’implémentation des deux fonctions reste classique. Dans chacune, nous copions 
simplement les champs de la structure Impi depuis l’objet source (rhs) vers l’objet 
destination (*thi s). Au lieu de copier des champs un par un, nous profitons du fait 
que le compilateur va créer des opérations de copie pour Impi et que ces opérations 
copieront automatiquement chaque champ. Nous réalisons donc les opérations de 
copie de Widget en appelant les opérations de copie générées par le compilateur pour 
Wi dget : : Impi . Dans le constructeur de copie, nous suivons le conseil 21, en choisissant 
d’utiliser std: :make_unique plutôt que d’appeler directement new. 

Pour la mise en œuvre de l’idiome Pimpl, nous conseillons le pointeur intelligent 
std : : unique_ptr car le pointeur pimpl dans un objet (par exemple dans un Widget) 
est le propriétaire exclusif de l’objet d’implémentation correspondant (par exemple 
l’objet Widget: : Impi ). Il est toutefois intéressant de noter que si, à la place de 
std: : unique_ptr, nous choisissions std: : shared_ptr pour pimpl, le conseil ici donné 
ne s’appliquerait plus. Il n’y aurait plus besoin de déclarer un destructeur dans Wi dget et, 
sans ce destructeur déclaré par l’utilisateur, le compilateur générerait les opérations de 
déplacement appropriées. Autrement dit, en supposant le code suivant dans widget . h : 


class Widget { // Dans "widget. h", 

publ ic: 

Widget! ) ; 

II Aucune décl aration pour 

Il le destructeur ou les opérations 

Il de déplacement. 


pri vate: 
struct Impi ; 

std: :shared_ptr<Impl> pimpl: Il std: :shared_ptr à la place 

1 : //de std: :unique_ptr. 


© 
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et le code client suivant qui inclut wi dget . h : 

Widget wl; 

auto w2 ( s td : :move(wl ) ) ; // Construire w2 par déplacement. 

wl = std: :move(w2) ; // Affecter wl par déplacement. 

la compilation et l’exécution se passent comme nous le souhaitons : wl est construit 
par défaut, sa valeur est déplacée dans w2, elle est ensuite redéplacée dans wl, et, pour 
finir, wl et w2 sont détruits (provoquant la destruction de l’objet Wi dget : : Impi pointé). 

L’origine de la différence de comportement liée à l’emploi de std: : un i q ue_pt r 
ou de std : : shared_ptr pour plmpl vient de la prise en charge des supprimeurs 
personnalisés par chacun de ces pointeurs intelligents. Pour std : : uni que_ptr, le type 
du supprimeur fait partie du type du pointeur intelligent et le compilateur peut ainsi 
générer des structures de données plus petites et un code d’exécution plus rapide. En 
raison de cette efficacité accrue, les types pointés doivent être complets si des fonctions 
spéciales générées par le compilateur (par exemple des destructeurs ou des opérations 
de déplacement) sont employées. Pour std: : shared_ptr, le type du supprimeur ne 
fait pas partie du type du pointeur intelligent. Cela impose des structures de données 
d’exécution plus volumineuses et du code un tantinet plus lent. En revanche, les types 
pointés n’ont pas besoin d’être complets pour utiliser les fonctions spéciales générées 
par le compilateur. 

Dans le contexte de l’idiome Pimpl, les caractéristiques de std: :unique_ptr et 
de std: :shared_ptr n’exigent pas véritablement des concessions, car la relation 
entre des classes comme Wi dget et des classes comme Wi dget : : Impi consiste en une 
propriété exclusive et std: :unique_ptr est donc l’outil adapté. Néanmoins, il est 
bon de savoir que dans d’autres situations, lorsqu’une propriété partagée existe (et 
où std: :shared_ptr est donc le choix de conception approprié), la définition des 
fonctions imposée par l’utilisation de std : : u n i q u e_p t r n’est plus requise. 

À retenir 

• L'idiome Pimpl diminue les temps de construction en réduisant les dépendances 
de compilation entre les clients des classes et les implémentations de ces classes. 

• Pour les pointeurs pimpl de type std: : uni que_ptr, il faut déclarer les fonctions 
membres spéciales dans l'en-téte de la classe, mais les mettre en oeuvre dans le 
fichier d'implémentation. Il faut procéder ainsi même lorsque les implémentations 
par défaut des fonctions conviennent. 

• Le conseil précédent s'applique à std: :unique_ptr, non à std: :shared_ptr. 
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Lorsqu’on les découvre pour la première fois, la sémantique du déplacement et la 
transmission parfaite semblent plutôt simples : 

• La sémantique du déplacement permet au compilateur de remplacer des opéra- 
tions de copie coûteuses par des opérations de déplacement plus légères. Tout 
comme les constructeurs de copie et les opérateurs d’affectation par copie nous 
donnent un contrôle sur le sens attribué à la copie des objets, les constructeurs 
de déplacement et les opérateurs d’affectation par déplacement nous offrent un 
contrôle sur la sémantique du déplacement. Celle-ci permet également de créer 
des types réservés au déplacement, comme std: :unique_ptr, std: : future et 
std: rthread. 

• La transmission parfaite permet d’écrire des templates de fonctions qui 
prennent des arguments quelconques et qui les relaient à d’autres fonctions en 
faisant en sorte que celles-ci reçoivent exactement les mêmes arguments que 
ceux qui ont été passés aux fonctions de retransmission. 

Les références rvalue sont le ciment qui lie ces deux fonctionnalités plutôt 
hétéroclites. Elles représentent le mécanisme sous-jacent du langage qui rend possibles 
la sémantique du déplacement et la transmission parfaite. 

Plus nous acquérons d’expérience avec ces fonctionnalités, plus nous réalisons 
que notre impression initiale relève de la métaphore de l’iceberg. Le monde de la 
sémantique du déplacement, de la transmission parfaite et des références rvalue est 
plus subtil qu’il ne paraît. Par exemple, std : :move n’effectue aucun déplacement et 
la transmission parfaite est imparfaite. Les opérations de déplacement ne sont pas 
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toujours moins coûteuses que la copie. Lorsque c’est le cas, leur prix est parfois plus 
élevé qu’attendu. Et elles ne sont pas toujours demandées dans un contexte où le 
déplacement est valide. La construction « type&& » ne représente pas toujours une 
référence rvalue. 

Plus nous avançons dans le monde de ces fonctionnalités, plus il semble rester 
des choses à découvrir. Heureusement, ce monde a des limites et ce chapitre va nous 
y conduire. Une fois ce point atteint, cette partie de C++1 1 prendra tout son sens. 
Par exemple, les conventions d’utilisation de std: :move et de std: :forward seront 
connues. La nature ambiguë de « type&& » ne sera plus perturbante. Les différents 
comportements des opérations de déplacement seront compris. Toutes ces pièces vont 
se mettre en place. Nous reviendrons alors à notre point de départ, là où la sémantique 
de déplacement, la transmission parfaite et les références rvalue semblaient plutôt 
simples. Mais cette fois-ci, elles le seront réellement. 

Dans les conseils de ce chapitre, il est particulièrement important de garder à 
l’esprit qu’un paramètre est toujours une lvalue, même si son type est une référence 
rvalue. Prenons l’instruction suivante : 

void f ( Wi dget&& w) ; 

Le paramètre w est une lvalue, même si son type est une référence rvalue sur un 
Wi dget. (Si cela vous surprend, retournez à la présentation des Ivalues et des rvalues 
qui débute à la section « Terminologie et conventions », page 2.) 

CONSEIL N° 23. COMPRENDRE STD: :M0VE ET STD: : FORWARD 

Pour aborder std : :move et std : : forward, il est plus commode d’expliquer ce que ces 
fonctions ne font pas. std: :move ne déplace rien, et std: : forward ne transmet rien. 
Au moment de l’exécution, elles ne font absolument rien. Elles ne génèrent aucun 
code exécutable. Pas un seul octet. 

std: :move et std: : forward sont simplement des fonctions (en réalité des templates 
de fonctions) de conversion de type, std : :move convertit systématiquement son argu- 
ment en une rvalue, tandis que std : : forward effectue cette conversion uniquement si 
une condition précise est remplie. Voilà tout. Cette explication soulève de nouvelles 
questions mais, fondamentalement, l’histoire s’arrête là. 

Pour que les choses soient plus concrètes, voici un exemple d’implémentation de 
std: :move en C++11. Elle n’est pas totalement confonne aux détails de la norme, 
mais elle en est très proche. 

templ ate<typename T> // Dans l’espace de noms std. 

typename remove_reference<T>: :type&& 
move(T&& param) 

I 

using Returnïype = // Déclaration d’alia s ; 

typename remove_reference<T>: :type&&; // voi r le conseil 9. 
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return static_cast<ReturnType>(param) ; 


Deux parties du code sont soulignées. La première est le nom de la fonction, car la 
spécification du type de retour est plutôt complexe et nous ne voulons pas que vous 
vous y perdiez. La seconde est la conversion de type qui forme l’essence de la fonction. 
Vous le constatez, std: :move prend une référence sur un objet (plus précisément une 
référence universelle ; voir le conseil 24) et renvoie une référence sur le même objet. 

La présence de « && » dans le type de retour de la fonction implique que std : :move 
renvoie une référence rvalue, mais, comme l’explique le conseil 28, si T est une 
référence lvalue, T&& devient une référence lvalue. Pour éviter que cela ne se produise, 
le trait de type (voir le conseil 9) std : : remove_reference est appliqué à T, garantissant 
que « && » concerne un type qui n’est pas une référence. De cette manière, std : :move 
retourne réellement une référence rvalue. Ce point est essentiel car les références 
rvalue renvoyées par des fonctions sont des rvalues. En résumé, std : :move convertit 
son argument en une rvalue, et c’est tout. 

En C++ 14, grâce à la déduction du type de retour d’une fonction (voir le conseil 3) 

et à l’alias de template std : : remove_ref erence_t de la bibliothèque standard (voir le 
conseil 9), nous pouvons implémenter std : :move de façon plus concise : 

templ ate<typename T> // C++14 ; toujours dans 

decltype(auto) move(T&& param) // l’espace de noms std. 

( 

using ReturnType = remove_reference_t<T>&&; 
return static_cast<ReturnType>(param) ; 


N’est-ce pas plus agréable à l’œil ? 

Puisque std : :move se contente de convertir son argument en une rvalue, il a été 
suggéré de changer son nom en quelque chose comme rval ue_cast. Mais peu importe, 
son nom est std : : move et l’important est de ne pas oublier ce que cette fonction fait 
et ne fait pas. Elle réalise une conversion de type. Elle n’effectue pas un déplacement. 

Les rvalues sont évidemment candidates au déplacement, et l’application de 
std: :move à un objet indique au compilateur que celui-ci peut être déplacé. Voilà 
pourquoi std : : move a pris le nom de l’opération qu’elle réalise : faciliter la désignation 
des objets qui peuvent être déplacés. 

En vérité, les rvalues sont seulement en général des candidates au déplacement. 
Supposons que nous écrivions une classe qui représente des annotations. Son construc- 
teur prend un paramètre std: : string qui correspond à l’annotation et copie son 
contenu dans une donnée membre. Munis des informations données au conseil 41, 
nous déclarons un paramètre par valeur : 
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class Annotation { 
public: 

explicit AnnotationCstd: :string text); Il Paramètre à copier, 

Il donc passé par valeur 

) ; Il selon le conseil 41. 

Mais le constructeur de Annotation doit simplement lire la valeur de text, sans 
avoir besoin de la modifier. Conformément à la tradition immémoriale qui veut que 
const soit appliqué dès que c’est possible, nous modifions la déclaration et rendons 

text const : 


class Annotation { 
publ ic: 

explicit Annotation(const std::string text) 


Pour éviter de payer le prix d’une opération de copie lors de la mémorisation de 
text dans la donnée membre, nous suivons le conseil 41 en appliquant std: :move à 
text et produisons ainsi une rvalue : 


class Annotation { 
publ ic: 

explicit Annotation(const std::string text) 

: val ue(std: :move(text) ) //"Déplacer" text dans value ; ce code 
{ ... I //n’a pas le comportement supposé ! 


pri vate: 

std: : st r i ng value; 


La compilation, l’édition de liens et l’exécution de ce code ne génèrent pas d’erreur. 
Le contenu de text est affecté à la donnée membre value. Le seul point qui ne soit 
pas parfaitement conforme à notre vision du fonctionnement de ce code est que le 
contenu de text n’est pas déplacé dans val ue, il y est copié. Certes, text est converti 
en rvalue par std: :move, mais text est déclaré const std: : string. Par conséquent, 
avant la conversion, text est une lvalue const std : : stri ng et la conversion produit 
une rvalue const std :: stri ng, mais son caractère const est préservé. 

Examinons les conséquences éventuelles lorsque le compilateur doit déterminer le 
constructeur destd::stringà appeler. Il existe deux possibilités : 

class string I // std::string est en réalité un 

public: // typedef pour std: :basic_string. 

string(const stri ng& rhs); // Constructeur de copie. 

string(string&& rhs); // Constructeur de déplacement. 
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Dans la liste d’initialisation du constructeur de Annotation, le résultat de 
std: :move(text) est une rvalue de type const std: :string. Cette rvalue ne peut pas 
être passée au constructeur de déplacement de std : : s tri ng, car celui-ci prend une 
référence rvalue sur un std: : string non const. En revanche, la rvalue peut être 
passée au constructeur de copie, car une référence Ivalue sur un const peut être liée à 
une rvalue const. L’initialisation de membre peut donc invoquer le constructeur de 
copie dans std : : stri ng, même si text a été converti en rvalue ! Un tel comportement 
est essentiel pour la conservation des caractères const. Puisque le déplacement d’une 
valeur en dehors d’un objet modifie généralement cet objet, le langage ne doit pas 
autoriser le passage d’objets const à des fonctions (par exemple les constructeurs de 
déplacement) qui peuvent les modifier. 

Nous pouvons tirer deux enseignements de cet exemple. Premièrement, les objets 
ne doivent pas être déclarés const s’ils doivent être impliqués dans des déplacements. 
Les demandes de déplacement sur des objets const sont transformées en opérations de 
copie. Deuxièmement, non seulement std : :move ne déplace rien du tout, mais elle ne 
garantit pas que l’objet cible de la conversion soit éligible au déplacement. La seule 
chose certaine est que le résultat de l’application de std : :move à un objet donne une 
rvalue. 

Pour std: :forward, le scénario est comparable à celui de std: :move, mais, là où 
std: :move convertit sans condition son argument en rvalue, std: :forward y procède 
sous certaines conditions, std : : forwa rd est une conversion de type conditionnelle. Pour 
comprendre les conditions de la conversion, rappelons l’usage type de std : : forwa rd. 
Le cas le plus fréquent est un template de fonction avec en paramètre une référence 
universelle passée à une autre fonction : 


void process(const Widget& IvalArg); 

II 

Traiter 

1 es 

1 val ues 

void process(Widget&& 

rval Arg) : 

II 

Trai ter 

1 es 

rval ues 

templ ateCtypename T> 


II 

Templ ate 

î qui 

passe 

void logAndProcess(T&& 

i 

param) 

II 

param à 

process . 

auto now = 


II 

Obteni r 

1 ’heure. 

std: rchrono: :system_clock: :now( ) ; 





makeLogEntry( "Appel 

de 'process' à”, 

now) ; 





process(std: :forward<TXparam) ) ; 


Examinons deux appels à 1 ogAndProcess, l’un avec une Ivalue, l’autre avec une 
rvalue : 


© 


Widget w; 

1 ogAndProcess(w) ; // Appel avec une Ivalue. 

1 ogAndProcess(std: :move(w) ) ; // Appel avec une rvalue. 

1 ogAndProcess transmet le paramètre param à la fonction process. Celle-ci est 
surchargée pour les lvalues et les rvalues. Lorsque nous appelons 1 ogAndProcess avec 
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une lvalue, nous nous attendons naturellement à ce que cette lvalue soit retransmise à 
process comme une lvalue, et que, lorsque 1 ogAndProcess est appelée avec une rvalue, 
la surcharge de process pour les rvalue soit invoquée. 

Mais param, comme n’importe quel paramètre de fonction, est une lvalue. Chaque 
appel à process dans 1 ogAndProcess voudra donc invoquer la surcharge de process 
pour les lvalues. Afin d’éviter cela, nous avons besoin d’un mécanisme qui puisse 
convertir pa ram en rvalue si et seulement si l’argument avec lequel pa r am a été initialisé 
- l’argument passé à 1 ogAndProcess - était une rvalue. C’est précisément la raison d’être 
de std : : forward. Voilà pourquoi std : : forward est une conversion conditionnelle : la 
conversion en rvalue est effectuée uniquement si son argument a été initialisé avec 
une rvalue. 

Vous vous demandez sans doute comment std:: forward peut savoir que son 
argument a été initialisé avec une rvalue. Par exemple, dans le code précédent, 
comment std : : forward peut-elle savoir si param a été initialisé à partir d’une lvalue ou 
d’une rvalue ? Voici la réponse courte : cette information est codée dans le paramètre 
de template T de 1 ogAndProcess. Ce paramètre est passé à std: : forward, qui récupère 
l’information codée. Tous les détails de ce fonctionnement se trouvent dans le 
conseil 28 . 

Puisque std::move et std::forward se résument à des conversions de type, 
leur seule différence étant que std: :move l’effectue systématiquement, tandis que 
std : : forward l’effectue parfois, vous pourriez vous demander s’il ne serait pas possible 
de se passer de std: :move et de se contenter de std: :forward. D’un point de vue 
purement technique, la réponse est oui: std:: forward peut être employée dans 
tous les cas. std::move n’est pas nécessaire. Bien entendu, aucune des fonctions 
n’est réellement nécessaire puisque nous pouvons écrire les conversions nous-mêmes, 
mais nous espérons que vous serez d’accord pour considérer cette approche plutôt 
maladroite. 

L’intérêt de std: :move réside dans son côté pratique, des potentialités d’erreur 
réduites et une meilleure clarté du code. Prenons une classe dans laquelle nous 
voulons suivre le nombre d’invocations du constructeur de déplacement. Nous 
avons simplement besoin d’un compteur static incrémenté lors de la construction 
par déplacement. En supposant que la seule donnée non statique dans la classe 
soit un std::string, voici la façon classique (c’est-à-dire en utilisant std::move) 
d’implémenter le constructeur de déplacement : 


cl ass Widget I 
publ ic: 

Wi dget ( Wi dget&& rhs) 

: s ( std : :move(rhs .s ) ) 
( ++moveCtorCal 1 s : I 


pri vate: 
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static std::size_t moveCtorCal 1 s ; 
std::string s; 


Voici la mise en œuvre du même comportement avec std : : forward : 


class Widget { 
publ i c : 

Widget(Wi dget&& rhs) 

: s (std: :forward<std: :stri ng>( rhs . s ) ) 
I ++moveCtorCall s ; ) 


// Implémentation, 

// non conventionnelle 
// non souhaitable. 
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Notons tout d’abord que std::move n’exige qu’un seul argument de fonction 
(rhs . s), alors que std : : forward a besoin d’un argument de fonction (rhs . s) et d’un 
argument de type de template (std: istring). Remarquons ensuite que le type passé 
à std: : forward ne doit pas être une référence, car il s’agit de la convention pour 
indiquer que l’argument passé est une rvalue (voir le conseil 28). En résumé, cela 
signifie que std : :move demande moins de saisie que std : : forward et que nous n’avons 
pas besoin de passer un argument de type qui encode le fait que l’argument passé est 
une rvalue. Cela élimine également la possibilité de passer un type incorrect (par 
exemple std : : stri ng&, qui conduirait à une construction non pas par déplacement 
mais par copie de la donnée membre s). 

Plus important encore, l’utilisation de std: :move signale une conversion incon- 
ditionnelle en rvalue, tandis que celle de std: : forward indique une conversion en 
rvalue uniquement pour des références auxquelles des rvalues ont été liées. Ces deux 
actions sont très différentes. La première configure généralement un déplacement, 
tandis que la seconde passe - transmet - simplement un objet à une autre fonction 
en conservant son caractère initial de lvalue ou de rvalue. Puisque ces actions sont si 
différentes, il est préférable d’avoir deux fonctions séparées (et des noms de fonction 
différents) pour les distinguer. 


À retenir 

• std: :move effectue une conversion inconditionnelle en rvalue. En soi, elle ne 
réalise aucun déplacement. 

• std: : forward convertit son argument en rvalue uniquement si celui-ci est lié à 
une rvalue. 

• Ni std: :move ni std: :forward n'effectue une opération à l'exécution. 
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CONSEIL N° 24. DISTINGUER LES RÉFÉRENCES 
UNIVERSELLES ET LES RÉFÉRENCES RVALUE 

Quelqu’un a dit « la vérité vous rendra libres » mais, lorsque les conditions s’y prêtent, 
un mensonge bien choisi peut également être libérateur. Ce conseil 24 est un tel 
mensonge. Mais, puisque nous parlons de logiciel, évitons le mot « mensonge » et 
préférons plutôt dire que ce conseil représente une « abstraction ». 

Pour déclarer une référence rvalue sur un type T, nous écrivons T&&. Il semble donc 
pertinent de supposer que la présence de « T&& » dans du code source dévoile une 
référence rvalue. Hélas, ce n’est pas aussi simple : 

void f(Widget&& param); 

Wi dget&& varl = WidgetO; 
auto&& var2 = varl ; 
templ ate<typename T> 

void f ( std : :vector<T>&& param); // Une référence rvalue. 
templ ate<typename T> 

void f ( T&& param); II Pas une référence rvalue. 

En réalité, « T&& » a deux significations différentes. L’une correspond évidemment 
à une référence rvalue. De telles références affichent le comportement attendu : elles 
se lient uniquement à des rvalues et leur principale raison d’être est d’identifier des 
objets qui peuvent être impliqués dans des déplacements. 

La seconde interprétation pour « T&& » est soit une référence rvalue, soit une 
référence lvalue. Dans le code source, de telles références ressemblent à des références 
rvalue (c’est-à-dire « T&& »), mais elles ont le comportement de références lvalue 
(c’est-à-dire « T& »). En raison de leur double nature, elles peuvent être liées aussi bien 
à des rvalues (comme des références rvalue) qu’à des lvalues (comme des références 
lvalue). Par ailleurs, elles peuvent se lier à des objets const ou non, à des objets 
volatile ou non, et même à des objets const et volatile. Elles peuvent se lier à, 
virtuellement, n’importe quoi. Ces références à la souplesse sans précédent méritent 
leur propre nom. Nous les appelons références universelles 1 . 

Les références universelles se rencontrent dans deux contextes. Le plus répandu est 
celui des paramètres d’un template de fonction, comme dans cet extrait de l’exemple 
de code précédent : 

I templ ate<typename T> 

void f ( T&& param); // param est une référence universelle. 

1. Le conseil 25 explique qu’il faut pratiquement toujours appliquer std : : forward aux références 
universelles et, au moment où cet ouvrage était mis sous presse, certains membres de la communauté 
C++ ont commencé à désigner les références universelles par forwarding references. 


Il Une référence rvalue. 

Il Une référence rvalue. 

Il Pas une référence rvalue. 
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Les déclarations auto représentent le second contexte, notamment celle-ci tirée 
du code précédent : 

auto&& var2 = varl; // var2 est une référence universelle. 

Le point commun entre ces contextes réside dans l’existence de la déduction de 
type. Dans le template f, le type de param est déduit et, dans la déclaration de var2, le 
type de cette variable est déduit. Faisons une comparaison avec les exemples suivants 
(également tirés du code précédent), pour lesquels la déduction de type est absente. 
Lorsque nous rencontrons « T&& » sans déduction de type, nous sommes face à une 
référence rvalue : 

void f(Widget&& param); // Aucune déduction de type ; 

// param est une référence rvalue. 

Wi dget&& varl = WidgetO; // Aucune déduction de type ; 

// varl est une référence rvalue. 

En tant que références, les références universelles doivent être initialisées. L’ini- 
tialiseur d’une référence universelle détermine si elle représente une référence rvalue 
ou une référence Ivalue. Si l’initialiseur est une rvalue (respectivement une lvalue), 
la référence universelle correspond à une référence rvalue (respectivement une 
référence lvalue). Lorsque les références universelles sont des paramètres de fonction, 
l’initialiseur est fourni à l’endroit de l’appel : 

templ ateCtypename T> 

void f ( T&& param); // param est une référence universelle. 

Widget w; 

f (w) ; // lvalue passée à f ; param est de type 

// Wi dget& (une référence Ivalue). 

f (std: :move(w) ) ; // rvalue passée à f ; param est de type 

// Wi dget&& (une référence rvalue). 

Pour qu’une référence soit universelle, la déduction de type est nécessaire, mais 
elle n’est pas suffisante. La forme de la déclaration de la référence doit également 
être correcte et les contraintes sont plutôt strictes. Elle doit être précisément « T&& ». 
Reprenons l’exemple suivant extrait du code montré précédemment : 

I templ ateCtypename T> 

void f ( std : :vector<T>&& param); // param est une référence rvalue. 

À l’invocation de f , le type T est déduit (sauf si l’appelant le spécifie explicitement ; 
nous ne nous occuperons pas de ce cas limite). Mais la déclaration du type de pa ram est 
non pas de la forme « T&& » mais de la forme « std : : vector<T>&& ». Puisque cela écarte 
la possibilité que param soit une référence universelle, param est donc une référence 
rvalue, ce que confirmera le compilateur si nous tentons de passer une lvalue à f : 
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std: :vector<int> v; 

f(v); Il Erreur ! Une 1 val ue ne peut pas être 

Il liée à une référence rvalue. 

Même la simple présence du qualificateur const suffit à éliminer la candidature 
d’une référence au statut de référence universelle. 


I templ ate<typename T> 

void f(const T&& param); // param est une référence rvalue. 

Si, dans un template, un paramètre de fonction est de type « T&& », nous pourrions 
penser qu’il est possible d’y voir une référence universelle. Mais ce n’est pas le cas. En 
effet, le fait d’être un template ne garantit pas la mise en place de la déduction de type. 
Examinons la fonction membre push_back dans std : : vector : 


templ ate<cl ass T, class Allocator = al 1 ocator<T>> // Extrait de C++, 
class vector ( 
publ ic: 

void push_back(T&& x); 

I; 


Le paramètre de push_back a bien la forme appropriée pour une référence univer- 
selle, mais, dans ce cas, la déduction de type n’a pas lieu. En effet, push_back ne peut 
pas exister sans une instanciation spécifique de vector dont elle doit faire partie, et 
le type de cette instanciation détermine pleinement la déclaration de push_back. Par 
exemple, supposons la déclaration suivante : 

std: :vector<Widget> v: 

Dans ce cas, le template std : : vector est instancié de la manière suivante : 

class vectoKWidget, allocator<Widget>> { 

publ ic: 

void push_back(Widget&& x); // Référence rvalue. 

I: 


Nous voyons à présent clairement que push_back ne déclenche aucune déduction 
de type. Cette fonction push_back pour vector<T> (il y en a deux, la fonction étant 
surchargée) déclare toujours un paramètre de type référence rvalue sur T. 

À l’opposé, la fonction membre empl ace_back de std : : vector, conceptuellement 
similaire, emploie la déduction de type : 


templ ateCcl ass T, class Allocator = al 1 ocator<T>> // Toujours extrait 
class vector I // de C++, 

publ ic: 
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templ ate <cl ass . . . Args> 

void empl ace_back(Args&&. . . a rgs ) ; 


-o 

O 


© 


Dans ce cas, le paramètre de type A rgs est indépendant du paramètre de type T 
de vector, et Args doit donc être déduit chaque fois que empl ace_back est appelée. 
(D’accord, Args est en réalité non pas un paramètre de type mais un ensemble de 
paramètres, mais, dans le cadre de cette discussion, nous pouvons le considérer comme 
un paramètre de type.) 

Le fait que le paramètre de type de empl ace_back se nomme Args, encore qu’il soit 
toujours une référence universelle, étaye notre commentaire précédent sur la forme 
d’une référence universelle, qui doit être « T&& ». Rien ne nous oblige à utiliser le nom 
de T. Par exemple, le template suivant prend une référence universelle, car la forme 
est correcte (« type&& ») et le type de param sera déduit (sauf, une fois encore le cas 
limite, si l’appelant le spécifie explicitement) : 

I templ ate<typename MyTempl ateType> // param est une référence 

void someFunc(MyTempl ateType&& param); // universelle. 

Nous avons indiqué précédemment que les variables auto peuvent également 
être des références universelles. De façon plus précise, les variables déclarées avec le 
type auto&& sont des références universelles, car la déduction de type a lieu et elles 
ont la forme appropriée (« T&& »). Les références universelles auto ne sont pas aussi 
répandues que celles utilisées pour les paramètres des templates de fonctions, mais 
nous les rencontrons de temps à autre en C++1 1. Elles sont beaucoup plus fréquentes 
en C++14, car les expressions lambda de C++14 peuvent déclarer des paramètres 
auto&&. Par exemple, pour écrire une expression lambda qui enregistre le temps passé 
dans une invocation de fonction quelconque, nous pouvons procéder de la manière 
suivante : 

auto timeFuncInvocation = 

[](auto&& func, auto&&... params) // C++14. 

I 

Lancer le chronomètre. 

std: :forward<decltype(func)Xfunc)( Il Invoquer func 

std: :forward<decl type(params)Xparams) . . . // avec params. 

); 

Arrêter le chronomètre et enregistrer le temps écoulé. 


Si votre réaction au code « std: :forward<decl type(£>7a bla bla)> » dans l’ex- 
pression lambda est « Punaise mais c’est quoi ce truc ! », il est probable que vous 
n’ayez pas encore lu le conseil 33. Ne vous en occupez pas. Le point important dans 
ce conseil concerne les paramètres auto&& déclarés par l’expression lambda, func est 
une référence universelle qui peut être liée à n’importe quel objet, lvalue ou rvalue 
invocable, args correspond à zéro ou plusieurs références universelles (c’est-à-dire 
un ensemble de paramètres de référence universelle) qui peuvent être liées à un 
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nombre quelconque d’objets de type arbitraire. Grâce aux références universelles auto, 
nous avons une fonction timeFunc Invocation qui peut chronométrer l’exécution 
de quasiment n’importe quelle fonction. (Pour plus d’informations sur la différence 
entre « toutes les fonctions » et « quasiment n’importe quelle fonction », consultez le 
conseil 30.) 

N’oubliez pas que l’intégralité de ce conseil, sur les bases des références universelles, 
est un mensonge, une « abstraction ». La vérité sous-jacente se nomme réduction de 
référence ( reference collapsing) et sera dévoilée au conseil 28. Cependant, la vérité 
n’enlève rien à l’utilité de l’abstraction. En faisant la différence entre les références 
rvalue et les références universelles, nous pouvons avoir une lecture plus précise du 
code source (« Est-ce que ce T&& se lie à des rvalues uniquement ou à n’importe 
quoi ? ») et nous pouvons éviter les ambiguïtés lors des échanges avec nos collègues 
(« J’utilise une référence universelle ici, non une référence rvalue... »). Cela nous 
permet également de donner un sens aux conseils 25 et 26, qui se fondent sur cette 
distinction. Accueillez donc l’abstraction, et savourez-la. Tout comme les lois du 
mouvement de Newton (qui sont techniquement incorrectes) sont généralement aussi 
utiles et plus faciles à appliquer que la théorie de relativité générale d’Einstein (« la 
vérité »), la notion de référence universelle est normalement préférable à l’analyse des 
détails de la réduction de référence. 


À retenir 

• Si un paramètre de template de fonction est de type T&& pour un type T déduit, 
ou si un objet est déclaré avec auto&&, le paramètre ou l'objet est une référence 
universelle. 

• Si la forme de la déclaration du type n'est pas exactement type&&, ou si la 
déduction de type n'a pas lieu, type&& correspond à une référence rvalue. 

• Les références universelles correspondent à des références rvalue si elles sont 
initialisées avec des rvalues, et à des références Ivalue si l'initialisation se fait avec 
des Ivalues. 


CONSEIL N° 25. UTILISER 

STD: : MOV E SUR DES RÉFÉRENCES RVALUE, 

STD: : FORWARD SUR DES RÉFÉRENCES UNIVERSELLES 


Les références rvalue se lient uniquement aux objets compatibles avec le déplacement. 
Si un paramètre est une référence rvalue, nous savom que l’objet auquel il est lié peut 
être déplacé : 


class Widget I 

Widget(Widget&& rhs); // rhs fait assurément référence à un 

Il objet candidat au déplacement. 
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Nous voudrions donc passer de tels objets à d’autres fonctions de sorte que celles-ci 
puissent exploiter le fait qu’ils sont des rvalues. Pour cela, nous convertissons en 
rvalues les paramètres liés à de tels objets. Comme l’explique le conseil 23, c’est le 
rôle de std: :move, qui a été créée dans ce but : 


class Widget { 
publ i c : 

Wi dget ( Wi dget&& rhs) // rhs est une référence rvalue. 

: name(std: :move(rhs.name)) , 
p ( std : :move(rhs.p)) 


pri vate: 

std: :string name; 

std: :shared_ptr<SomeDataStructure> p: 


Les références universelles peuvent, quant à elles (voir le conseil 24), être liées 
à des objets susceptibles d’être déplacés. Elles doivent être converties en rvalues 
uniquement si elles ont été initialisées avec des rvalues. Le conseil 23 explique que 
c’est précisément le rôle de std : : forward : 


class Widget { 
publ ic: 

templ ate<typename T> 

void setName(T&& newName) // newName est une 

I narre = std: :forward<TXnewName) ; I // référence universelle. 


En résumé, les références rvalue doivent être systématiquement converties en rvalues 
(avec std : : move) lorsqu’elles sont transmises à d’autres fonctions, car elles sont toujours 
liées à des rvalues, tandis que les références universelles doivent être converties de façon 
conditionnelle en rvalues (avec std: : forward) lorsqu’elles sont relayées, car elles ne 
sont que parfois liées à des rvalues. 

Le conseil 23 explique que l’utilisation de std : : forward sur des références rvalue 
permet d’obtenir le comportement approprié, mais le code source est plus verbeux, 
sujet aux erreurs et littéral. Il est donc préférable d’éviter d’appliquer std: : forward 
aux références rvalue. En revanche, il faut proscrire l’utilisation de std: :move avec 
des références universelles, car cela peut conduire à une modification inattendue des 
Ivalues (par exemple des variables locales) : 


© 


class Widget { 
publ ic: 

templ ate<typename T> 

void setName(T&& newName) // Référence universelle. 

I name = std: :move(newName) : I // Le code compile, mais il 

// est très très mauvais ! 
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pri vate: 

std: : s t r i n g name; 

std: : shared_ptr<SomeDataStructure> p; 

1; 


std: :str1ng getWidgetName( ) ; Il Fonction fabrique. 

Widget w; 

auto n = getWidgetName( ) ; Il n est une variable locale. 

w.setName(n) ; Il Déplace n dans w ! 

Il La valeur de n est à présent inconnue. 

Dans cet exemple, la variable locale n est passée à w. setName, que l’appelant est 
en droit de considérer comme une opération en lecture seule sur n. Mais, puisque 
setName utilise std: :move en interne pour convertir systématiquement en rvalue la 
référence données en paramètre, la valeur de n est déplacée dans w.name et, suite à 
l’appel à setName, n revient avec une valeur indéfinie. De tels comportements peuvent 
conduire les développeurs au désespoir, voire à la violence. 

Vous pourriez soutenir que setName n’aurait pas dû déclarer son paramètre en tant 
que référence universelle. Ces références ne peuvent pas être const (voir le conseil 24), 
mais il est certain que setName ne devrait pas modifier son paramètre. Vous pourriez 
souligner que si setName avait simplement été surchargée pour les lvalues const et 
pour les rvalues, le problème aurait pu être évité : 


class Widget I 
publ ic: 

void setName( const std::string& newName) 
{ name = newName; ) 


// Affectation à partir 
// d’une Ivalue const. 


void setName(std: :string&& newName) 
( name = std: :move(newName) ; 1 


// Affectation à partir 
// d’une rvalue. 


Cette solution fonctionne, dans ce cas, mais elle a des inconvénients. Première- 
ment, le code est plus long à écrire et à maintenir (deux fonctions à la place d’un seul 
template). Deuxièmement, elle peut être moins efficace. Prenons, par exemple, cette 
utilisation de setName : 

w. setName( "Adel a Novak"); 

Avec la version de setName qui prend une référence universelle, la chaîne de 
caractères littérale "Adel a Novak” est passée à setName, où elle est transmise à 
l’opérateur d’affectation du std: : string dans w. La donnée membre name de w est 
donc affectée directement à partir de la chaîne littérale, sans intervention d’objets 
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std:: string temporaires. En revanche, avec les versions surchargées de setName, 
un objet std: : string temporaire est créé afin d’y lier le paramètre de setName. Ce 
std : : s tri ng temporaire est ensuite déplacé dans la donnée membre de w. Un appel 
à setName entraîne donc l’exécution d’un constructeur de std: : string (pour créer 
l’objet temporaire), d’un opérateur d’affectation par copie de std:: string (pour 
déplacer newName dans w.name) et d’un destructeur de std: : string (pour détruire 
l’objet temporaire). Cette suite d’exécutions est certainement plus onéreuse que la 
seule invocation de l’opérateur d’affectation de std: :string avec un pointeur const 
char*. Le coût supplémentaire variera d’une implémentation à l’autre et son impact 
sera plus ou moins important selon les applications et les bibliothèques, mais il n’en 
reste pas moins que remplacer un template prenant une référence universelle par 
deux fonctions surchargées pour les références lvalue et rvalue augmentera le temps 
d’exécution dans certains cas. Si nous généralisons l’exemple en ayant une donnée 
membre de Widget de type arbitraire (au lieu de savoir qu’elle est un std: : string), 
la baisse des performances peut croître énormément, car le d éplacement de cer tains 
types est beaucoup plus coûteux que celui d’un std : : st ri ng (voir le conseil 29). 

Cependant, le problème le plus grave de la surcharge pour les lvalues et les 
rvalues n’est pas la quantité ou le caractère littéral du code source, pas plus que ses 
performances à l’exécution. Le souci le plus important vient du manque d’évolutivité 
de la conception. Widget: : setName ne prenant qu’un seul paramètre, seules deux 
surcharges sont nécessaires. En revanche, pour les fonctions qui prennent plusieurs 
paramètres, chacun pouvant être une lvalue ou une rvalue, le nombre de surcharges 
croît de façon géométrique : n paramètres demandent 2 r surcharges. Mais il y a 
plus grave encore. Certaines fonctions, les fonctions templates pour être précis, 
prennent un nombre de paramètres illimité, chacun pouvant être une lvalue ou une 
rvalue. std: :make _shared en est un parfait exemple, tout comme, depuis C++14, 
std: :make_unique (voir le conseil 21). Examinons les déclarations de leurs surcharges 
les plus employées : 


T3 

n 


© 


templ ate<cl ass T, 
shared_ptr<T> make. 

templ ate<cl ass T, 
unique_ptr<T> make. 


lass... Args> 
shared(Args&&. . . 

lass... Args> 
unique(Args&&. . . 


Il 

args) ; 

II 

args) ; 


Extrait de C++11. 

Extrait de C++14. 


Avec de telles fonctions, il est impossible d’envisager des surcharges pour les lvalues 
et les rvalues : la seule solution consiste à utiliser des références universelles. Et, à 
l’intérieur de ces fonctions, nous pouvons vous l’assurer, std : : f orwa rd est appliquée 
aux références universelles passées en paramètres lorsqu’elles sont transmises à d’autres 
fonctions. C’est exactement de cette manière que nous devons procéder. 

En réalité, le plus souvent, à un moment donné, mais pas nécessairement dès le 
début. Dans certains cas, nous voudrons utiliser à plusieurs reprises dans une même 
fonction l’objet qui est lié à une référence rvalue ou à une référence universelle, et nous 
devrons nous assurer qu’il n’est pas déplacé tant que nous en avons besoin. Dans ce 
cas, nous appliquerons std: :move (pour les références rvalue) ou std: :forward (pour 
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les références universelles) uniquement lors de la dernière utilisation de la référence. 
Par exemple : 

templ ateCtypename T> Il text est une référence 

void setSignText(T&& text) Il universelle. 

( 

sign.setïext(text) ; Il Utiliser text, mais 

Il sans le modifier. 

auto now = Il Obtenir l’heure. 

std: :chrono: :system_clock: :now( ) ; 
signHistory.add(now, 

std: : forward<TXtext) ) ; Il Convertir sous condition 
1 II text en rvalue. 

Dans cet exemple, nous voulons être certains que la valeur de text n’est pas 
modifiée par si gn . setText, car nous souhaitons employer cette valeur dans un appel 
à si gn H i s tory . add. std : : forward est donc appliquée uniquement lors de la dernière 
utilisation de la référence universelle. 

Pour std: :move, nous pouvons tenir le même raisonnement (c’est-à-dire appliquer 
std: :move à une référence rvalue lors de sa dernière utilisation), mais il est important 
de noter que, dans de rares cas, nous voudrons appeler std: :move_if_noexcept à 
la place de std: :move. Pour comprendre quand et pourquoi ces cas se présentent, 
consultez le conseil 14. 

Si le retour de la fonction se fait par valeur et s’il concerne un objet lié à 
une référence rvalue ou une référence universelle, nous appliquerons std: :move ou 
std : : forward au moment du renvoi de la référence. Prenons l’exemple d’une fonction 
operator+ qui effectue l’addition de deux matrices, celle de gauche étant une rvalue 
(sa zone de mémoire peut donc être réutilisée pour y placer la matrice résultante) : 

Matrix // Retour par valeur. 

operator+(Matrix&& lhs, const Matrix& rhs) 

1 

lhs += rhs; 

return std : :move( lhs); II Déplacer lhs dans 

I II la valeur de retour. 

En convertissant 1 hs en rvalue dans l’instruction return (avec std : :move), 1 hs est 
déplacée à l’emplacement de la valeur de retour de la fonction. Supposons que nous 
omettions l’appel à std: :move : 

I Matrix // Comme précédemment. 

operator+(Matrix&& lhs, const Matrix& rhs) 



lhs += rhs; 
return lhs; 


II Copier lhs dans 
Il la valeur de retour. 
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Dans ce cas, puisque 1 h s est une lvalue, le compilateur est obligé de la copier à 
l’emplacement de la valeur de retour. Si le type Matrix prend en charge la construction 
par déplacement, qui est plus efficace que la construction par copie, l’application de 
std: :move dans l’instruction return permet d’obtenir un code plus performant. 

Si Matrix ne prend pas en charge le déplacement, sa conversion en rvalue ne 
posera pas de problème, car la rvalue sera simplement copiée par le constructeur de 
copie de Matri x (voir le conseil 23). Si Matri x est ensuite modifiée pour prendre en 
charge le déplacement, operator+ en bénéficiera automatiquement dès sa compilation. 
C’est pourquoi nous n’avons rien à perdre (et, dans certains cas, beaucoup à gagner) 
en appliquant std : :move aux références rvalue qui sont renvoyées par des fonctions 
dont le retour se fait par valeur. 

La situation est comparable pour les références universelles et std : : forward. 
Examinons une fonction template reduceAndCopy qui prend un objet Fraction 
potentiellement non réduit, en fait la réduction et retourne une copie de la valeur 
réduite. Si l’objet initial est une rvalue, sa valeur doit être déplacée dans la valeur de 
retour (évitant ainsi le coût d’une copie), mais s’il s’agit d’une lvalue, une copie doit 
être effectuée : 


templ ate<typename T> 

Fraction // Retour par valeur. 

reduceAndCopy(T&& frac) // Référence universelle en paramètre. 

( 

frac. reduce( ) ; 

return std: :forward<T>(frac) ; // rvalue déplacée et lvalue copiée 

1 // dans la valeur de retour. 

Si l’appel à std: : forward était absent, frac serait systématiquement copiée dans 
la valeur de retour de reduceAndCopy. 

Certains programmeurs reprennent l’information précédente et tentent de 
l’étendre à des situations où elle ne s’applique pas. Voici leur raisonnement : 
«Si utiliser std::move sur une référence rvalue passée en paramètre et copiée 
dans la valeur de retour transforme la construction par copie en construction par 
déplacement, je peux obtenir la même optimisation pour les variables locales que je 
renvoie. » Autrement dit, ils pensent que si une fonction retourne une variable locale 
par valeur, comme dans l’exemple suivant : 

Widget makeWidgetO // Version "par copie" de makeWidget. 

I 

Widget w; // Variable locale. 

// Configurer w. 

return w; Il "Copier" w dans la valeur de retour. 

I ) 

ils peuvent l’« optimiser » en transformant la « copie » en déplacement : 
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Widget makeWidgetO II Version par déplacement de makeWidget. 

I 

Widget w; 

return std: :move(w) ; Il Déplacer w dans la valeur de retour 

I II {à ne surtout pas faire !) 

L’emploi des guillemets devrait vous indiquer que ce raisonnement présente 
quelques défauts. Mais qu’elle en est la raison ? 

II est erroné car le comité de normalisation a de l’avance sur ces programmeurs 
vis-à-vis de ce type d’optimisation. Il est depuis longtemps reconnu que la version « par 
copie » de makeWidget peut éviter la copie de la variable locale w en la construisant 
dans la zone de mémoire allouée à la valeur de retour de la fonction. Il s’agit de 
l’optimisation de la valeur de retour (RVO, return value optùnization) et elle a été 
expressément adoptée par la norme C++ depuis qu’elle existe. 

Exprimer ce bienfait par des mots demande un travail méticuleux, car nous 
voulons autoriser une telle élision de copie uniquement là où elle n’affectera pas le 
comportement observable du logiciel. En paraphrasant la prose légaliste (sans doute 
toxique) de la norme, cette approbation particulière stipule que le compilateur peut 
éluder la copie (ou le déplacement) d’un objet local 1 dans une fonction avec un retour 
par valeur si (1) le type de l’objet local est identique à celui retourné par la fonction 
et si (2) l’objet local est l’élément retourné. Avec ces éléments en tête, revenons à la 
version « par copie » de makeWi dget : 

Widget makeWidgetO // Version "par copie" de makeWidget. 

( 

Widget w; 

return w; // "Copier” w dans la valeur de retour. 

I 


Dans ce cas, les deux conditions sont satisfaites et, vous pouvez nous croire sur 
parole, tout compilateur C++ sérieux mettra en œuvre la RVO de façon à éviter la 
copie de w. Autrement dit, la version « par copie » de makeWidget n’effectue aucune 
copie. 

La version par déplacement de makeWi dget a bien le comportement sous-entendu 
par son appellation (en supposant que Widget dispose d’un constructeur par dépla- 
cement) : elle déplace le contenu de w à l’emplacement de la valeur de retour 
de makeWidget. Mais pourquoi le compilateur n’utilise-t-il pas la RVO de façon à 


1. Les objets locaux éligibles comprennent la plupart des variables locales (à l’instar de w dans 
makeWidget) ainsi que les objets temporaires créés pour les besoins de l’instruction return. Les 
paramètres d’une fonction ne sont pas concernés. Certaines personnes font une différence entre 
l’application de la RVO aux objets locaux nommés et non nommés (c’est-à-dire temporaires). Ils 
réservent le terme RVO aux objets non nommés et désignent son application aux objets nommés 
sous l’expression « optimisation de la valeur de retour nommée » (N RVO, narned return value 
optimization] I. 
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supprimer le déplacement, de nouveau en construisant w dans la zone de mémoire 
allouée à la valeur de retour de la fonction ? La réponse est simple : il ne le peut pas. 
La condition (2) stipule que la RVO peut être mise en œuvre uniquement si l’élément 
retourné est un objet local, ce qui n’est pas le cas dans la version par déplacement de 
makeWi dget. Examinons de nouveau son instruction return : 

return std: :move(w) ; 

L’élément retourné n’est pas l’objet local w, mais une référence sur vi - le résultat de 
std: :move(w). Retourner une référence à un objet local ne remplit pas les conditions 
nécessaires à la RVO et le compilateur doit donc déplacer w dans la zone de mémoire 
réservée à la valeur de retour de la fonction. Les développeurs qui tentent d’aider 
leur compilateur dans ses optimisations en appliquant std : :move à une variable locale 
retournée restreignent en réalité les possibilités d’optimisation ! 

Il ne faut pas oublier que la RVO est une optimisation. Le compilateur n’est 
pas obligé d’éluder les opérations de copie et de déplacement, même s’il en est 
capable. Mais peut-être sommes-nous paranoïaques et imaginons-nous que notre 
compilateur veut nous punir par des opérations de copie, uniquement parce qu’il 
en a la possibilité. Ou peut-être sommes-nous suffisamment informés pour reconnaître 
que, dans certains cas, la RVO est difficile à appliquer, par exemple lorsque différents 
chemins de contrôle dans une fonction renvoient des variables locales différentes. 
(Le compilateur doit générer le code de construction de la variable locale appropriée 
dans la mémoire allouée à la valeur de retour de la fonction, mais comment peut- il 
déterminer la variable locale appropriée ?) Dans ce cas, vous serez disposé à payer le 
prix d’un déplacement en contrepartie de la garantie de l’absence du coût d’une copie. 
Autrement dit, vous pensez qu’il est raisonnable d’appliquer std: :tïiove à un objet 
local retourné, simplement parce que vous savez que vous n’aurez jamais à payer pour 
une copie. 

Dans ce cas, appliquer std: :move à un objet local serait encore une mauvaise 
idée. La section de la norme qui approuve la RVO poursuit en expliquant que si les 
conditions de la RVO sont satisfaites, mais que le compilateur décide de ne pas éluder 
la copie, l’objet retourné doit être traité comme une rvalue. En effet, la norme exige 
que, si la RVO est permise, soit l’élision de copie a lieu, soit std : :move est appliqué 
implicitement aux objets locaux retournés. Par conséquent, dans la version « par 
copie » de makeWi dget : 

Widget makeWidgetO // Comme précédemment. 

I 

Widget w; 
return w ; 

1 

le compilateur doit éluder la copie de w ou doit considérer que la fonction est écrite 
de la manière suivante : 
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Widget makeWidget( ) 

I 

Widget w; 

return std: :move(w) ; // Traiter w comme une rvalue, car 

I // l’élision de copie est absente. 

Le cas des paramètres de fonction passés par valeur est comparable. Ils ne sont 
pas éligibles à l’élision de copie en tant que valeur de retour de la fonction, mais le 
compilateur doit les traiter comme des rvalues s’ils sont renvoyés. Par conséquent, si 
notre code source ressemble à ceci : 


Widget makeWidgetCWidget w) // Paramètre par valeur de même type 

( // que le retour de la fonction. 


return w; 


le compilateur doit considérer qu’il est écrit de la façon suivante : 


Widget makeWidget(Widget w) 

1 

return std: :move(w) ; // Traiter w comme une rvalue. 


Cela signifie que si nous utilisons std: :move sur un objet local renvoyé par une 
fonction dont le retour se fait par valeur, nous ne pouvons pas aider le compilateur 
(s’il ne met pas en place l’élision de copie, il doit traiter l’objet local comme une 
rvalue), mais nous pouvons certainement le gêner (en empêchant la RVO). Il existe 
des cas où l’application de std : : move à une variable locale peut se révéler raisonnable 
(c’est-à-dire lorsque nous la passons à une fonction et savons que nous ne l’utiliserons 
plus), mais pas dans celui d’une instruction return qui serait sinon éligible à la RVO 
ou qui retourne un paramètre par valeur. 


À retenir 

• Appliquer std::move aux références rvalue et std::forward aux références 
universelles au moment de leur dernière utilisation. 

• Appliquer le même traitement aux références rvalue et aux références 
universelles qui sont renvoyées par des fonctions dont le retour se fait par 
valeur. 

• Ne jamais appliquer std: :move ou std: :forward aux objets locaux qui seraient 
sinon éligibles à l'optimisation de la valeur de retour. 
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CONSEIL N° 26. ÉVITER LA SURCHARGE 
SUR LES RÉFÉRENCES UNIVERSELLES 

Supposons que nous ayons besoin d’une fonction qui prend un nom en paramètre, 
journalise la date et l’heure courantes, et ajoute le nom à une structure de données 
globale. Voici le code auquel nous pourrions arriver : 

std: :multiset<std: :string> names; // Structure de données globale. 

void 1 ogAndAdd(const std : : str i ng& name) 

( 

auto now = // Obtenir l’heure, 

std: :chrono: :system_clock: :now( ) ; 

log(now, "logAndAdd" ) ; // Créer l'entrée du journal. 

// Ajouter name à la structure 
// de données globale ; voir 
// le conseil 42 pour emplace. 

Ce code ne semble pas déraisonnable, mais il n’est pas aussi efficace qu’il pourrait 
l’être. Examinons trois appels potentiels : 

std::string petNamei "Darl a" ) ; 

logAndAdd(petName) ; // Passer un std::string 

// en Ivalue. 

logAndAdd(std: :string("Persephone”) ) : // Passer un std : : str i ng 

// en rvalue. 

logAndAddC’Patty Dog”); // Passer une chaîne littérale. 

Dans le premier appel, le paramètre name de 1 ogAndAdd est lié à la variable petName. 
À la fin de la fonction logAndAdd, name est passé à names .empl ace. Puisque name est 
une Ivalue, il est copié dans names. Il est impossible d’éviter cette copie, car une Ivalue 
(petName) a été transmise à 1 ogAndAdd. 

Dans le deuxième appel, le paramètre name est lié à une rvalue (le std: : string 
créé explicitement à partir de "Persephone"). Puisque name est lui-même une Ivalue, 
il est copié dans names, mais nous reconnaissons que, en principe, sa valeur pourrait 
être déplacée dans names. Dans cet appel, nous payons une copie, mais nous pourrions 
faire en sorte d’obtenir uniquement un déplacement. 

Dans le troisième appel, le paramètre name est à nouveau lié à une rvalue, mais il 
s’agit cette fois-ci d’un std: :string temporaire créé implicitement à partir de "Patty 
Dog”. Comme dans le deuxième appel, name est copié dans names, mais, dans ce cas, 
l’argument initialement passé à 1 ogAndAdd est une chaîne littérale. Si cette chaîne était 
passée directement à emplace, il serait inutile de créer un std : : stri ng temporaire. À la 
place, emplace utiliserait la chaîne littérale pour créer l’objet std : : stri ng directement 


names .empl ace(name) : 
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dans le std : :mul ti set. Par conséquent, dans ce troisième appel, nous payons pour une 
copie d’un std : : stri ng, alors qu’il n’y a aucune véritable raison de payer ne serait-ce 
que pour un déplacement, et encore moins pour une copie. 

Nous pouvons apporter une solution à l’inefficacité des deuxième et troisième 
appels, en modifiant logAndAdd afin qu’elle prenne en paramètre une référence 
universelle (voir le conseil 24) et, en accord avec le conseil 25, appeler std: : forward 
sur cette référence en la passant à empl ace. Le résultat parle de lui-même : 


templ ate<typename T> 

void 1 ogAndAdd ( T&& name) 

I 

auto now = std: :chrono: :system_clock: :now( ) ; 


1og(now, "logAndAdd"): 
names .empl a ce (std: :forward<T>(name) 
I 

std: :string petName( "Darl a" ) : 
logAndAdd(petName) ; 

logAndAdd (std: :stri ngC’Persephone") ) ; 

logAndAddC’Patty Dog"); 


// Comme précédemment. 

// Comme précédemment, copier 
// une 1 val ue dans un multiset. 

Il Déplacer une rvalue au lieu 
Il de la copier. 

Il Créer un std:: string dans 
Il un multiset au lieu de copier 
Il un std::string temporaire. 


Génial, efficacité optimale ! 

Si l’histoire s’arrêtait là, nous pourrions nous retirer fièrement. Cependant, nous 
avons omis de préciser que les clients n’ont pas toujours un accès direct aux noms 
nécessaires à logAndAdd. Certains ne disposent que d’un indice dont logAndAdd se 
sert pour rechercher le nom dans un tableau. Pour ces clients, nous surchargeons 

1 ogAndAdd : 

std::string nameFrom!dx(int idx); // Retourner le nom qui 

// correspond à idx. 

void 1 ogAndAdd ( i nt idx) // Nouvelle surcharge. 

1 

auto now = std: :chrono: :system_clock: :now( ) ; 

logtnow, "logAndAdd"); 

names .empl ace(nameFromIdx(idx) ) ; 

1 


La résolution des appels aux deux surcharges se fait comme attendu : 


std::string petName( "Darl a" ) ; 


// Comme précédemment. 
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logAndAdd(petName) ; Il Comme précédemment, ces 

1 ogAndAdd ( s td : :string( "Persephone" ) ) ; Il appels invoquent tous 
1 ogAndAdd ( "Patty Dog M ); Il la surcharge T&&. 

1 ogAndAdd ( 22 ) ; Il Appeler la surcharge int. 


En réalité, la résolution se passe correctement uniquement si nous n’en demandons 
pas trop. Supposons qu’un client utilise un short pour mémoriser l’indice et le passe à 
1 ogAndAdd : 

short nameldx; 

// Attribuer une valeur à nameldx. 
logAndAdd(nameldx) ; // Erreur ! 
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Le commentaire de la dernière ligne est un tantinet succinct. Expliquons ce qui se 
passe. 

1 ogAndAdd a deux surcharges. Celle qui prend en argument une référence univer- 
selle peut déduire que T est un short et constitue donc une correspondance exacte. La 
surcharge pour un paramètre i nt peut correspondre à l’argument short uniquement 
au travers d’une promotion. D’après les règles de résolution normale de la surcharge, 
une correspondance exacte a la priorité sur une correspondance par promotion. En 
conséquence, la surcharge pour les références universelles est invoquée. 

Dans cette fonction surchargée, le paramètre name est lié au short passé en 
paramètre. std::forward est ensuite appliquée à name lors de l’invocation de la 
fonction membre emplace sur naines (un std: :multiset<std: :string>). A son tour, 
elle le retransmet scrupuleusement au constructeur destd::string. Puisqu’il n’existe 
aucun constructeur de std : : stri ng qui prenne un short, l’appel au constructeur de 
std:: string à l’intérieur de l’appel à mul ti set :: emplace dans l’appel à 1 ogAndAdd 
échoue. Tout cela uniquement parce que la surcharge avec une référence universelle 
offre une meilleure correspondance pour un short que celle avec un int. 

Les fonctions qui prennent en paramètres des références universelles sont les 
plus gourmandes de C++. Leur instanciation crée des correspondances exactes pour 
quasiment n’importe quel type d’argument. (Les quelques sortes d’arguments non 
concernés sont décrites au conseil 30.) C’est pourquoi il est préférable de ne jamais 
combiner surcharge et références universelles : une surcharge avec une référence 
universelle aspire beaucoup plus de types d’arguments que son développeur ne s’y 
attend généralement. 

Une solution à ce comportement indésirable consiste à écrire un constructeur 
de transmission parfaite. Une petite modification de l’exemple de 1 ogAndAdd illustre 
le problème. Au lieu d’écrire une fonction qui prend soit un std: : string, soit un 
indice utilisé pour rechercher un std : : stri ng, imaginons une classe Person dont les 
constructeurs remplissent le même objectif : 
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class Person I 
public: 


templ ate<ty pename T> 


explicit Person(T&& n) 

n 

: name(std: :forward<T>(n) ) (! 

\ n 

explicit Person(int idx) 

n 

: name(nameFromIdx( idx) ) {) 



Constructeur de transmission parfaite : 
initialise la donnée membre. 

Constructeur avec un int. 


pri vate: 

std: :string name; 


Comme c’était le cas avec 1 ogAndAdd, le passage d’un type entier autre qu’un i nt 
(par exemple std : : s i ze_t, short, long, etc.) déclenchera l’appel de la surcharge 
du constructeur pour une référence universelle à la place de celle pour un int, et 
conduira à un échec de la compilation. Dans cet exemple, le problème est toutefois 
pire, car les surcharges dans Person sont plus nombreuses qu’on ne le voit. Le 
conseil 17 explique que, sous certaines conditions, C++ générera des constructeurs 
de copie et de déplacement, même si la classe comprend un template de constructeur 
dont l’instanciation permet d’obtenir la signature du constructeur de copie ou de 
déplacement. Si ces constructeurs sont générés pour Person, sa déclaration équivaut 
en réalité à la suivante : 


class Person I 
publ ic: 

templ ate<typename T> // 

explicit Person(T&& n) 

: name(std: :forward<T>(n) ) (} 

explicit Person(int idx); // 

Person(const PersonS rhs); // 

II 

Person(Person&& rhs); Il 


II 


Constructeur de transmission parfaite. 

Constructeur avec un int. 

Constructeur de copie 
(généré par le compilateur). 

Constructeur de déplacement 
(généré par le compilateur). 


I 


Ce comportement n’est évident que pour les programmeurs qui ont passé beaucoup 
de temps avec des compilateurs ou qui en ont développés, et qui ont oublié ce qu’était 
un être humain : 


Person p( "Nancy" ) ; 

auto cloneOfP(p); // Créer un nouveau Person à partir de p : 

//ce code ne compile pas ! 



Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 26. Éviter la surcharge sur les références universelles 



Dans cet exemple, nous essayons de créer un objet Person à partir d’un autre 
Per son, ce qui semble évidemment un cas de construction par copie, (p est une lvalue 
et nous pouvons donc oublier toute idée de « copie » accomplie par une opération 
de déplacement.) Mais ce code n’invoque pas le constructeur de copie. Il va appeler 
le constructeur de transmission parfaite, qui va tenter d’initialiser la donnée membre 
std : : stri ng de Person avec un objet Person (p). Puisque std : : stri ng n’a pas de 
constructeur qui prend un Person, le compilateur abandonne et nous gratifie de 
messages d’erreur éventuellement longs et incompréhensibles. 

Vous vous demandez sans doute pourquoi le constructeur de transmission parfaite 
est appelé à la place du constructeur de copie, alors que l’initialisation du Person se 
fait à partir d’un autre Person. Si l’initialisation est bien celle-là, le compilateur se 
doit nénamoins de respecter les règles de C++ et, dans ce cas, il s’agit de celles de la 
résolution des appels aux fonctions surchargées. 

Voici le raisonnement suivi par le compilateur. Puisque cl oneOf P est initialisé avec 
une lvalue non const (p), le template de constructeur peut être instancié de façon à 
prendre une lvalue non const de type Person. Suite à cette instanciation, la classe 
Person ressemble à la suivante : 


class Person I 
publ ic: 

explicit Person(Person& n) 

: name(std: :forward<Person&>(n) ) 


// Instancié à partir du 
// template de transmission 
// parfaite. 


explicit Person(int idx); 


// Comme précédemment. 


Person(const Person& rhs); 


// Constructeur de copie 
// (généré par le compilateur). 


-o 

n 


© 


Dans l’instruction 


auto cloneOfP(p); 

p peut être passé au constructeur de copie ou au template instancié. L’appel du 
constructeur de copie nécessiterait l’ajout de const à p afin de correspondre au type 
du paramètre de ce constructeur, mais l’appel au template instancié ne requiert 
aucun ajout. La surcharge générée à partir du template donne donc une meilleure 
correspondance et le compilateur fait ce pourquoi il a été conçu : générer un appel à 
la fonction qui présente la meilleure correspondance. Par conséquent, la « copie » de 
lvalue non const de type Person est prise en charge non pas par le constructeur de 
copie mais par le constructeur de transmission parfaite. 

Si nous modifions légèrement l’exemple de sorte que l’objet à copier soit const, 
nous entendons un autre son de cloche : 
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I const Person cp( "Nancy" ) ; Il L’objet est à présent const. 

auto cloneOfP(cp) ; Il Appeler le constructeur de copie ! 

Puisque l’objet à copier est à présent const, nous obtenons une correspondance 
exacte avec le paramètre du constructeur de copie. Le template de constructeur peut 
également être instancié pour obtenir la même signature : 

class Person { 
publ ic: 

explicit Person(const Person& n); // Instancié à partir du 

// template. 

PersonCconst Person& rhs); // Constructeur de copie 

// (généré par le compilateur). 


Mais cette instanciation ne compte pas, car l’une des règles de la résolution de 
la surcharge en C++ stipule que si une instanciation de template et une fonction 
non template (c’est-à-dire une fonction normale) donnent toutes deux la même 
correspondance pour un appel de fonction, la fonction normale doit avoir la priorité. 
Le constructeur de copie (une fonction normale) surpasse donc le template instancié 
pour obtenir la même signature. 

(Si vous vous demandez pourquoi un compilateur génère un constructeur de copie 
lorsqu’il a la possibilité d’obtenir la signature de celui-ci en instanciant un template 
de constructeur, consultez le conseil 17.) 

L’interaction entre les constructeurs de transmission parfaite et les opérations de 
copie et de déplacement générées par le compilateur apporte des soucis supplémen- 
taires lorsque l’héritage est de la partie. En particulier, les implémentations classiques 
des opérations de copie et de déplacement dans une classe dérivée affichent un 
comportement assez surprenant. Examinons la situation suivante : 


class Spécial Person : public Person { 
publ ic: 

Spécial Person (const Spécial Person& 

: Person(rhs) 

( ... 1 


Spécial Person(Special Person&& rhs) 

: Person(std: :move(rhs)) 


rhs) // Constructeur de copie ; 

// appelle le constructeur de 
// transmission de la classe 
// de base! 

// Constructeur de déplacement : 
// appelle le constructeur de 
// transmission de la classe 
// de base! 


Les commentaires révèlent que les constructeurs de copie et de déplacement de la 
classe dérivée n’invoquent pas leur homologue de la classe de base, mais le constructeur 
de transmission parfaite de celle-ci ! Pour en comprendre la raison, remarquons que les 
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fonctions de la classe dérivée utilisent des arguments de type Spécial Person à passer 
à leur classe de base, puis subissent les conséquences de l’instanciation de template 
et de la résolution de la surcharge pour les constructeurs de la classe Person. Pour 
finir, le code ne compile pas car std : : stri ng n’offre pas de constructeur qui prend un 
Speci al Person. 

Vous devriez à présent être convaincu que la surcharge sur des paramètres qui 
sont des références universelles doit être évitée autant que possible. D’accord, mais 
comment pouvons-nous procéder si nous avons besoin d’une fonction qui transmet la 
plupart des types d’arguments et doit en traiter certains de façon particulière ? Puisque 
les réponses à cette question sont nombreuses, nous allons y consacrer le conseil 27. 

À retenir 

• La surcharge sur des références universelles conduit presque toujours à l'appel 
de cette surcharge dans des situations plus nombreuses qu'imaginé. 

• Les constructeurs de transmission parfaite soulèvent des difficultés, car ils 
donnent généralement de meilleures correspondances que les constructeurs 
de copie pour des Ivalues non const, et ils peuvent empêcher les appels aux 
constructeurs de copie et de déplacement d'une classe de base depuis une 
classe dérivée. 


CONSEIL N° 27. SE FAMILIARISER AVEC 
LES ALTERNATIVES À LA SURCHARGE 
SUR LES RÉFÉRENCES UNIVERSELLES 

Le conseil 26 explique que la surcharge sur les références universelles peut conduire à 
divers problèmes, tant au niveau des fonctions membres (en particulier les construc- 
teurs) que des fonctions indépendantes. Toutefois, elle présente également des 
exemples où cette surcharge se révèle utile. Si seulement elle pouvait se comporter 
comme nous l’aimerions ! Ce conseil décrit comment arriver au comportement 
souhaité, que ce soit par une conception qui évite les surcharges sur les références 
universelles ou par une utilisation qui contraint les types des arguments auxquels elles 
peuvent correspondre. 

Les explications se fondent sur les exemples donnés au conseil 26. Si cela vous 
semble nécessaire, n’hésitez pas à le (re)lire avant de poursuivre. 


© 


Renoncer à la surcharge 

Le premier exemple du conseil 26, logAndAdd, illustre parfaitement les nombreuses 
fonctions qui permettent d’éviter les inconvénients de la surcharge sur les références 
universelles en donnant simplement des noms différents à ce qui serait des surcharges. 
Ainsi, les deux surcharges de 1 ogAndAdd pourraient être renommées en 1 ogAndAddName 
et 1 ogAndAddNameldx. Malheureusement, cette solution ne convient pas dans le 
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deuxième exemple étudié, le constructeur de Person, car les noms des constructeurs 
sont fixés par le langage. De toute manière, qui voudrait abandonner la surcharge ? 


Passer par cons t T& 

Une autre approche consiste à revenir à du C++98 et à remplacer le passage par une 
référence universelle par un passage par une référence Ivalue sur un const. Il s’agit 
en réalité de la première alternative envisagée dans le conseil 26. Son inconvénient 
réside dans une conception qui manque d’efficacité. Conscients des problèmes liés à 
l’interaction entre les références universelles et la surcharge, nous pourrions préférer 
garder les choses simples et perdre un peu en efficacité. 


Passer par valeur 

Une méthode qui permet souvent de composer avec les performances sans augmenter 
la complexité consiste, contre toute attente, à remplacer le passage par référence des 
paramètres par un passage par valeur. Elle suit le conseil 41, où nous préconisons de 
passer des objets par valeur lorsque nous savons qu’ils seront copiés. Puisque tous les 
détails de ce fonctionnement et de l’efficacité obtenue se trouvent dans le conseil 41, 
nous nous contenterons ici de montrer son utilisation avec Person : 


class Person I 
publ ic: 

explicit Person(std: :string n) 
: nametstd: :move(n) ) I) 


// Remplace le constru cteur T&& ; 

// voir le conseil 41 pour l’emploi 
//de std: :move. 


explicit Person(int idx) // Comme précédemment. 

: name(nameFromIdx(idx)) Il 


private: 

std: rstring name; 


Puisque std : : s tri ng n’offre aucun constructeur qui prend uniquement un entier, 
tous les arguments int et équivalents à int destinés à un constructeur de Person 
(par exemple std : : si ze_t, short, 1 ong) arrivent à la surcharge sur int. De manière 
comparable, tous les arguments de type std : : stri ng (et tout ce qui permet de créer un 
std : : stri ng, par exemple des littéraux comme " Ruth" ) sont transmis au constructeur 
qui attend un std: : string. Aucune surprise pour le code appelant. Vous pourriez 
souligner que certaines personnes pourraient être surprises que la représentation d’un 
pointeur nul par 0 ou NU LL invoque la surcharge sur int, mais, dans ce cas, nous 
leur conseillons de lire attentivement le conseil 8 jusqu’à ce qu’elles oublient l’idée 
d’utiliser 0 ou NU LL comme pointeur nul. 
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Utiliser le tag dispatching 

Avec le passage par référence 1 value sur c on s t ou le passage par valeur, la transmission 
parfaite n’est pas prise en charge. Si la raison d’utiliser une référence universelle vient 
de la transmission parfaite, nous n’avons pas le choix. Pourtant, nous ne souhaitons pas 
abandonner la surcharge. Dans ce cas, si nous ne voulons pas renoncer à la surcharge 
ni aux références universelles, comment pouvons-nous éviter la surcharge sur les 
références universelles ? 

En réalité, ce n’est pas difficile. La résolution des appels aux fonctions surchargées 
passe par l’analyse de tous les paramètres de toutes les surcharges et de tous les 
arguments dans les appels, puis par le choix de la fonction qui donne la meilleure 
correspondance globale (en prenant en compte toutes les combinaisons de paramètres 
et d’arguments). En général, un paramètre de type référence universelle permet 
d’obtenir une correspondance exacte quel que soit l’argument passé, mais, si la 
référence universelle fait partie d’une liste de paramètres qui ne sont pas tous des 
références universelles, il suffit d’une correspondance moins bonne sur ces paramètres 
pour qu’une surcharge ne soit plus retenue. Voilà les bases du tag dispatching. Un 
exemple facilitera la compréhension de la description qui va suivre. 

Nous allons appliquer le tag dispatching à l’exemple 1 ogAndAdd donné au conseil 26. 
Voici le code correspondant : 


std: :multiset<std: : s tri ng> names; // Structure de données globale. 

templ ateCtypename T> // Créer l’entrée du journal et 

void 1 ogAndAdd(T&& name) // ajouter name à la structure 

( // de données, 

auto now = std: :chrono: :system_clock: :now( ) ; 
log(now, "1 ogAndAdd" ) ; 
names . empl ace (std: :forward<TXname) ) ; 


-o 

O 
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En soi, cette fonction affiche le comportement souhaité, mais, si nous introduisons 
la surcharge sur i nt afin de rechercher des objets par un indice, nous retombons dans 
les problèmes décrits au conseil 26. L’objectif de ce conseil est de les éviter. Au lieu 
d’ajouter la surcharge, nous allons revoir 1 ogAndAdd de façon à mettre en place une 
délégation vers deux autres fonctions, l’une pour les valeurs entières, l’autre pour tous 
les autres types. 1 ogAndAdd acceptera tous les types d’arguments, qu’il s’agisse d’entiers 
ou non. 

Les deux fonctions qui réalisent le véritable travail se nommeront 1 ogAndAdd Impi . 
Autrement dit, nous allons utiliser la surcharge. Puisque l’une des fonctions prendra 
une référence universelle, nous aurons la combinaison de la surcharge et des références 
universelles. Cependant, chaque fonction va également prendre un second paramètre, 
qui précisera si l’argument passé est un entier. C’est grâce à ce second paramètre que 
nous éviterons les difficultés décrites au conseil 26. En effet, nous ferons en sorte que 
le second paramètre soit le critère de sélection de la surcharge. 

Fin du blablabla, voici le code de la nouvelle version presque correcte de 1 ogAndAdd : 
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templ ate<typename T> 
void logAndAdd(T&& name) 

{ 

1 ogAndAddlmpl (std: : forward<T>(name) , 

std: :is_integral<T>( ) ) ; Il Pas tout à fait correct. 


Cette fonction transmet son paramètre à 1 ogAndAddlmpl, mais elle lui passe 
également un argument indiquant si le type du paramètre (T) correspond à un entier. 
Tout au moins, c’est ce que nous supposons. Lorsque l’argument entier est une rvalue, 
le comportement est correct. Mais, comme l’explique le conseil 28, si un argument 
lvalue est passé à la référence universelle name, le type déduit pour T sera une référence 
Ivalue. Autrement dit, si une lvalue de type i nt est passé à 1 ogAndAdd, le type déduit 
pour T sera int&. Il ne s’agit pas d’un type entier, car les références ne sont pas des 
entiers. Cela signifie que std : : i s_i ntegral <T> retournera faux pour tout argument 
qui est une lvalue, même si celui-ci représente une valeur entière. 

Identifier le problème équivaut à le résoudre, car la bibliothèque standard de C+ + 
dispose d’un trait de type (voir le conseil 9), std: : remove_reference, qui effectue 
l’opération suggérée par son nom et dont nous avons besoin : retirer tout qualificatif 
de référence à un type. Voici donc la bonne manière d’écrire 1 ogAndAdd : 


templ ate<typename T> 
void 1 ogAndAdd ( T&& name) 
I 


logAndAddlmpl ( 
std: :forward<TXname) , 

std: : is_i ntegral <typename std: :remove_reference<T>: :type>( ) 

): 

I 


L’affaire est réglée. (C++ 14 permet de gagner au niveau de la saisie en remplaçant 
le code en exergue par std : : remove_reference_t<T> ; voir le conseil 9.) 

Nous pouvons à présent nous focaliser sur la fonction invoquée, logAndAddlmpl. 
Elle présente deux surcharges, la première correspondant uniquement aux types 
non entiers (c’est-à-dire les types pour lesquels std :: is_i ntegral <typename 
std: : remove_reference<T>: :type> est faux) : 


templ ate<typename T> 

void logAndAddlmpl (T&& name, std: :false_type) 

1 

auto now = std: :chrono: :system_clock: :now( ) ; 

loginow, ”1 ogAndAdd" ) ; 

names .empl a ce (std: :forward<TXname) ) : 


// Argument 
// non entier : 
// 1 'ajouter à 
// la structure 
// de données 
// globale. 


Ce code est simple, dès lors que la mécanique derrière le paramètre en exergue 
est comprise. Conceptuellement, 1 ogAndAdd passe à logAndAddlmpl un booléen qui 
indique si un type entier a été transmis à 1 ogAndAdd. Cependant, true et fal se sont des 
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valeurs à l’exécution, alors que nous avons besoin de la résolution de la surcharge - un 
phénomène qui se produit à la compilation - pour choisir la surcharge de 1 ogAndAddlmpl 
appropriée. Autrement dit, nous avons besoin d’un type qui correspond à true et 
d’un autre pour fal se. Ce besoin est suffisamment fréquent pour que la bibliothèque 
standard apporte le nécessaire sous les noms std: :true_type et std: :false_type. 
L’argument passé à 1 ogAndAddlmpl par logAndAdd est un objet dont le type dérive de 
std: :true_type lorsque T est un entier, et de std: :false_type lorsque T n’est pas un 
entier. En résumé, cette surcharge de 1 ogAndAdd Impi sera sélectionnée pour l’appel 
effectué dans 1 ogAndAdd uniquement si T n’est pas un entier. 

La seconde surcharge s’occupe du cas opposé : lorsque T est un type entier. 
1 ogAndAddlmpl recherche alors le nom qui correspond à l’indice passé et le transmet 
simplement à 1 ogAndAdd : 

std::string nameFromldxi int idx); // Comme dans le conseil 26. 

void 1 ogAndAddlmpl (int idx, std: :true_type) // Agument entier : 

( // rechercher le nom 

logAndAdd(nameFromIdx(idx) ) ; // et le passer à 

1 // logAndAdd. 

Puisque la version de 1 ogAndAddlmpl qui prend un indice recherche le nom 
correspondant et transmet celui-ci à logAndAdd (dans laquelle il est passé à l’autre 
surcharge de 1 ogAndAddlmpl avec std: :forward), nous évitons l’ajout du code de 
journalisation dans les deux variantes de 1 ogAndAddlmpl . 

Dans cette conception, les types std : :true_type et std: : fal se_type représentent 
des « étiquettes » ( tag ) dont le seul but est d’orienter la résolution de la surcharge 
dans la direction souhaitée. Vous remarquerez que nous n’avons même pas nommé 
ces paramètres. Ils n’ont aucun rôle à l’exécution et, en réalité, nous espérons que 
le compilateur déterminera que les paramètres étiquettes ne sont pas utilisés et qu’il 
les retirera de l’image exécutable du programme. (Certains compilateurs le font, tout 
au moins parfois.) L’appel aux fonctions surchargées dans logAndAdd « distribue » 
( dispatch ) le travail à la surcharge appropriée grâce à la création de l’objet étiquette 
adéquat. Voilà l’origine du nom donné à cette conception : tag dispatching. Il s’agit 
d’un élément standard de la métaprogrammation par template et plus vous examinerez 
le code des bibliothèques C++ modernes, plus vous le rencontrerez. 

Dans notre cas, l’important n’est pas tant le fonctionnement du tag dispatching 
mais sa capacité à nous laisser combiner les références universelles et la surcharge sans 
rencontrer les problèmes décrits au conseil 26. La fonction de distribution - 1 ogAndAdd 
- prend un paramètre non contraint de type référence universelle, mais elle n’est pas 
surchargée. Les fonctions d’implémentation — 1 ogAndAddlmpl — sont surchargées et 
prennent un paramètre de type référence universelle. Cependant, la résolution des 
appels de ces fonctions ne dépend pas uniquement de ce paramètre mais également du 
paramètre étiquette, dont les valeurs permettent de déterminer une correspondance 
valide avec une seule surcharge. En résumé, la surcharge invoquée est sélectionnée par 
cette étiquette. Le fait que le paramètre de type référence universelle donnera toujours 
une correspondance exacte pour son argument ne compte pas. 
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Contraindre des templates qui prennent des références universelles 

Le tag dispatching se fonde sur l’existence d’une unique (non surchargée) fonction dans 
l’API cliente qui distribue le travail à effectuer à des fonctions d’implémentation. La 
création d’une fonction de distribution non surchargée se révèle en général facile, 
mais le second cas problématique du conseil 26, celui du constructeur de transmission 
parfaite pour la classe Person, fait exception. Puisque le compilateur peut décider 
lui-même de générer des constructeurs de copie et de déplacement, il ne nous suffît pas 
d’écrire un seul constructeur et d’y employer la distribution. En effet, certains appels 
aux constructeurs pourront se trouver dans des fonctions produites par le compilateur 
qui contournent le mécanisme de distribution. 

En réalité, le véritable problème ne vient pas du fait que les fonctions générées 
par le compilateur contournent parfois le système de distribution par étiquette, mais 
qu’elle ne le contourne pas à chaque fois. Virtuellement, nous voulons toujours que 
le constructeur de copie d’une classe traite les demandes de copie des lvalues de ce 
type, mais, le conseil 26 le montre, en offrant un constructeur qui prend une référence 
universelle, celui-ci (et non le constructeur de copie) est appelé lors de la copie de 
lvalue non const. Ce conseil explique également que si une classe de base déclare 
un constructeur de transmission parfaite, celui-ci est généralement appelé lorsque des 
classes dérivées implémentent leurs constructeurs de copie et de déplacement de façon 
classique, même si le comportement correct voudrait que les constructeurs de copie et 
de déplacement de la classe de base soient invoqués. 

Dans de telles situations, lorsqu’une fonction surchargée prenant une référence 
universelle est plus gourmande que nous le voudrions, mais pas suffisamment pour 
jouer le rôle d’une seule fonction de distribution, la solution du tag dispatching ne 
convient pas. Nous avons besoin d’une technique différente, qui nous permette de 
réduire les conditions d’emploi du template de fonction dont fait partie la référence 
universelle. La solution se nomme std : : enabl e_i f . 

std : : enabl e_i f permet d’obliger le compilateur à considérer qu’un template précis 
n’existe pas. De tels templates sont dits inactifs. Par défaut, tous les templates sont 
actifs, mais un template qui utilise std : : enabl e_i f ne l’est que si la condition indiquée 
à std : : enabl e_i f est satisfaite. Dans notre cas, nous souhaitons activer le constructeur 
de transmission parfaite de Person uniquement si le type passé n’est pas Person. Dans 
le cas contraire, nous voulons le désactiver (autrement dit, qu’il soit ignoré par le 
compilateur), car cela conduit au traitement de l’appel par le constructeur de copie 
ou de déplacement de la classe, précisément ce que nous souhaitons lorsqu’un objet 
Person est initialisé à partir d’un autre objet Person. 

La manière d’exprimer cette idée ne pose pas de difficulté particulière, mais la 
syntaxe peut être rebutante, notamment si vous ne l’avez jamais rencontrée auparavant. 
Nous allons donc vous l’expliquer progressivement. Du code passe-partout entoure 
la condition indiquée dans std : : enabl e_i f et nous allons commencer par ce point. 
Voici la déclaration du constructeur de transmission parfaite de Person, où n’est 
montré que l’indispensable pour utiliser std : : enabl e_i f . Seule la déclaration de ce 
constructeur est donnée, car l’utilisation destd::enabl e_i f n’a aucune conséquence 
sur l’implémentation de la fonction. Elle reste identique à celle du conseil 26. 
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class Person { 
public: 

templ ate<typename T, 

typename = typename std: :enable_if<cond7t7'on>: :type> 

explicit Person(T&& n); 


Pour comprendre précisément ce qui se passe dans le code mis en exergue, nous 
avons le regret de vous conseiller de consulter d’autres sources, car les explications 
détaillées sont longues et nous n’avons pas assez de place dans cet ouvrage. (Faites 
une recherche sur « SFINAE » et sur std: :enable_if, car le fonctionnement de 
std : : enabl e_i f repose sur la technologie SFINAE.) Nous préférons nous focaliser sur 
l’expression de la condition qui détermine l’activation du constructeur. 

Notre condition est que T ne soit pas un Person, autrement dit que le template du 
constructeur ne soit activé que si T est un type autre que Person. Grâce au trait de 
type std : : i s_same qui permet de savoir si deux types sont identiques, nous pouvons 
imaginer que la condition appropriée est ! std : : i s_same<Person , T> : : val ue. (Notez-le 
« ! » au début de l’expression. Nous voulons que Person et T ne soient pas identiques.) 
Nous approchons de la bonne réponse, mais celle-ci n’est pas tout à fait correcte car, 
comme explique le conseil 28, le type déduit pour une référence universelle initialisée 
à partir d’une lvalue est toujours une référence lvalue. Autrement dit, pour un code 
semblable au suivant : 


"O 

n 
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I Person p( "Nancy"); 

auto cloneOfP(p); Il Initialiser à partir d’une lvalue. 

le type déduit pour T dans le constructeur universel sera Person&. Puisque les 
types Person et Person& sont différents, le résultat de std: : is_same<Person , Per- 
son&> : : val ue sera égal à faux. 

En réfléchissant plus précisément à ce que nous entendons par activation du 
template de constructeur de Person uniquement si T n’est pas un Person, nous réalisons 
que lorsque nous examinons T, nous voulons ignorer deux aspects : 

• S’il s’agit d’une référence. Dans notre contexte, les types Person, Person& et 
Person&& doivent être considérés comme identiques à Person. 

• S’il est const ou vol ati 1 e. De notre point de vue, un const Person, un vol ati 1 e 
Person et un const vol ati 1 e Person sont identiques à Person. 

Nous devons donc retirer de T les références et spécificateurs const et vol ati 1 e 
avant de vérifier si son type est identique à Person. Une fois encore, la biblio- 
thèque standard répond à notre besoin sous forme d’un trait de type : std: :decay. 
std: :decay<T>: : type équivaut à T, à l’exception du retrait des références et des 
qualificatifs const ou volatile. (Nous ne disons pas toute la vérité car, comme son 
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nom le suggère, std: :decay convertit également les types tableau et fonction en 
pointeurs [voir le conseil 1] mais, dans le contexte de cette discussion, std : : decay se 
comporte comme nous le décrivons.) La condition qui détermine l’activation de notre 
constructeur devient donc : 

! s td : : i s_same<Person , typename std: :decay<T>: :type>: : val ue 

Autrement dit, Person n’est pas identique au type T, sans tenir compte des 
références ni des qualificatifs const ou volatile. (Comme l’explique le conseil 9, 
le mot clé «typename» qui précède std:: decay est indispensable, car le type 
std: :decay<T>: :type dépend du paramètre de template T.) 

En insérant cette condition dans l’instruction std : : enabl e_i f précédente et en 
mettant le code en forme de façon à mieux distinguer les différents éléments, nous 
obtenons la déclaration suivante pour le constructeur de transmission parfaite de 

Person : 


class Person I 
publ ic: 
templ ate< 
typename T, 

typename = typename std: : enabl e_if< 

! std : :is_same<Person, 

typename std: :decay<T>: :type 
>: :value 


> 


> : :type 


explicit Person(T&& n); 


Vous n’avez sans doute jamais rencontré un tel code auparavant, alors réjouissez- 
vous de votre bonne fortune. Nous avons gardé cette conception pour la fin car nous 
avions une bonne raison. En effet, si l’une des autres approches permet d’éviter la 
combinaison des références universelles et de la surcharge (c’est quasiment toujours le 
cas), il faut l’adopter. Cependant, dès que la syntaxe fonctionnelle et la prolifération 
des crochets obliques ne gênent plus, cette dernière solution n’est pas si mauvaise, 
d’autant qu’elle apporte le comportement recherché. Avec la déclaration précédente, 
la construction d’un Person à partir d’un autre Person - lvalue ou rvalue, const ou 
non, vol ati 1 e ou non - ne se fera jamais en invoquant le constructeur qui prend une 
référence universelle. 

Et voilà, nous avons réussi ! 

En réalité, pas totalement. Un point mentionné au conseil 26 se balade encore et 
nous devons le fixer. 

Supposons qu’une classe dérivée de Person implémente les opérations de copie et 
de déplacement de manière conventionnelle : 
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class Spécial Person: public Person 1 
publ i c : 

Spécial Person (con s t Spécial Person& 

: Person(rhs) 


Spécial Person (Spécial Person&& rhs) 

: Person(std: :move( rhs) ) 


rhs) // Constructeur de copie ; 

// appelle le constructeur de 
// transmission de la classe 
// de base ! 

// Constructeur de déplacement ; 
// appelle le constructeur de 
// transmission de la classe 
// de base ! 
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Il s’agit du code que nous avons déjà montré au conseil 26, avec les mêmes 
commentaires, qui, hélas, restent d’actualité. Lorsque nous copions ou déplaçons 
un objet Spécial Person, nous supposons que la copie ou le déplacement des éléments 
de sa classe de base se fera avec les constructeurs de copie et de déplacement de 
cette classe. Cependant, dans ces fonctions, nous passons des objets Spécial Person 
aux constructeurs de la classe de base et, puisque Speci al Person n’est pas identique 
à Person (pas même après l’application de std: :decay), le constructeur pour les 
références universelles déclaré dans la classe de base est activé et instancié afin 
de donner une correspondance exacte pour un argument Speci al Person. Cette 
correspondance exacte surpasse les conversions de classe dérivée vers la classe de 
base qui seraient nécessaires pour lier les objets Speci al Person aux paramètres Person 
des constructeurs de copie et de déplacement de Person. Par conséquent, avec le code 
actuel, la copie et le déplacement d’objets Speci al Person confient au constructeur de 
transmission parfaite de Person la copie ou le déplacement des éléments de la classe 
de base ! Nous voilà de retour face aux problèmes décrits au conseil 26. 

La classe dérivée se contente de suivre les règles normales d’implémentation des 
constructeurs de copie et de déplacement dans une classe dérivée. La correction du 
problème doit donc se faire dans la classe de base et, plus précisément, au niveau de 
la condition d’activation du constructeur pour les références universelles de Person. 
Nous comprenons à présent que nous ne voulons pas activer ce constructeur pour 
n’importe quel type d’argument autre que Person, mais pour n’importe quel type 
d’argument autre que Person ou dérivé de Person. Fichu héritage ! 

Vous ne devriez pas être surpris d’apprendre que, parmi les traits de type standard, il 
en existe un qui permet de déterminer si un type dérive d’un autre : std : : i s_base_of. 
std : : i s_base_of<Tl , T2>: : val ue est vrai si T2 hérite de Tl. Puisque l’on considère 
qu’un type dérive de lui-même, std : : i s_base_of<T , T>::value est vrai. Cela va 
se révéler commode, car nous voulons revoir la condition sur le constructeur de 
transmission parfaite de Person afin qu’il ne soit activé que si le type T, après avoir 
retiré les références et les qualificatifs const et vol a t i 1 e, n’est ni Person ni une classe 
dérivée de Person. En remplaçant std : : i s_same par std : : i s_base_of, nous arrivons à 
nos fins : 
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class Person I 
public: 
templ ate< 
typename T, 

typename = typename std: : enabl e_i f < 

! s td : : is_base_of<Person , 

typename std: :decay<T>: :type 
> : : val ue 

> : :type 

> 

explicit Person(T&& n); 


Avec C++ 1 1 , nous avons terminé le code. Si nous utilisons C++ 14, ce code 
fonctionne encore, mais nous pouvons exploiter les alias de template pour nous 
débarrasser de « typename » et de « : :type » : 


class Person I 
public: 
templ ate< 
typename T, 

typename = std: .-enabl e_if_t< 

! s td : : i s_base_of<Person , 

std: :decay_t<T> 
>: : val ue 

> 


> 

explicit Person(T&& n); 


// C++14. 

// Moins de code ici. 
// Et ici . 

// Et là. 


D’accord, nous avons menti. Ce n’est pas tout à fait terminé, mais nous sommes 
vraiment très proches de la fin. 

Nous avons vu comment utiliser std : : enabl e_i f de façon à désactiver le construc- 
teur pour les références universelles de Person lorsque le type de l’argument doit être 
pris en charge par les constructeurs de copie et de déplacement de la classe, mais nous 
n’avons pas encore vu comment l’appliquer pour différencier les arguments entiers et 
non entiers. Il s’agissait après tout de notre objectif initial, ce problème d’ambiguïté 
sur le constructeur n’étant apparu qu’en cours de route. 

Tout ce que nous avons à faire est (1) d’ajouter une surcharge de construction 
d’un Person pour traiter les arguments entiers et (2) d’augmenter les contraintes sur le 
template de constructeur afin de le désactiver pour de tels arguments : 

class Person I 
publ ic: 
templ ate< 



Dunod - Toute reproduction non autorisée est un délit. 


Conseil n° 27. Se familiariser avec les alternatives à la surcharge sur les références universelles 



typename T, 

typename = std: :enable_if_t< 

! s td : : i s_base_of<Person , std: :decay_t<T>>: :value 

&& 

! std : :is_integral<std: :remove_reference_t<T>>: :value 


> 

explicit Person(T&& n) // 
: name(std: :forward<T>(n) ) // 
( ... ) // 

explicit Person(int idx) // 
: name(nameFromIdx(idx) ) // 
{ ... } 


Constructeur pour std::string et 
les arguments convertibles en 
std: :string. 

Constructeur pour les arguments 
entiers. 


// Constructeurs de copie et 
// de déplacement, etc. 


pri vate: 

std: :string name; 


Et voilà ! La beauté du code n’apparaîtra peut-être qu’à l’amateur de métapro- 
grammation de template, mais il n’en reste pas moins que cette approche permet 
d’accomplir le travail et de belle manière. Puisqu’elle se fonde sur la transmission 
parfaite, nous obtenons une efficacité maximale, et, puisqu’elle maîtrise la combinai- 
son des références universelles et de la surcharge au lieu de la bannir, elle peut être 
appliquée dans des situations (par exemple pour les constructeurs) où la surcharge est 
inévitable. 


Avantages et inconvénients 
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Les trois premières techniques décrites dans ce conseil — abandonner la surcharge, 
passer par const T& et passer par valeur - spécifient un type pour chaque paramètre 
des fonctions à appeler. Les deux dernières techniques - tag dispatching et contraindre 
l’éligibilité d’un template - exploitent la transmission parfaite et ne spécifient donc 
pas les types des paramètres. Ce choix fondamental, spécifier ou non un type, a des 
conséquences. 

En règle générale, la transmission parfaite est plus efficace car elle évite la création 
d’objets temporaires dans le seul but de se conformer au type de la déclaration d’un 
paramètre. Dans le cas du constructeur de Person, elle permet de transmettre une 
chaîne de caractères littérale, comme "Nancy", au constructeur du std: : string qui 
se trouve à l’intérieur de Person. En revanche, les techniques qui n’utilisent pas la 
transmission parfaite doivent créer un objet std: : string temporaire à partir de la 
chaîne littérale afin de respecter la spécification de paramètre du constructeur de 
Person. 

La transmission parfaite a toutefois des inconvénients. Tout d’abord, certains 
arguments ne peuvent pas être transmis parfaitement, même s’ils peuvent être passés à 
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des fonctions qui prennent des types spécifiques. Le conseil 30 détaille ces cas où la 
transmission parfaite échoue. 

Ensuite, les messages d’erreur produits lorsque le client passe des arguments 
invalides ne sont pas toujours très compréhensibles. Supposons, par exemple, qu’un 
client qui crée un objet Person passe une chaîne de caractères littérale constituée de 
ch a r 1 6_t (un type apporté par C++1 1 pour représenter des caractères sur 16 bits) à la 
place de char (dont est constitué un std: : stri ng) : 

I Person p(u”Konrad Zuse"); // "Konrad Zuse" est composé de 

// caractères de type const charl6_t. 

Avec les trois premières approches étudiées dans ce conseil, le compilateur verra 
que les constructeurs disponibles prennent un Int ou un std: : string, et générera 
donc un message d’erreur plus ou moins clair indiquant que la conversion depuis un 
const cha rl 6_t [12] vers un int ou un std: : s t r i n g est impossible. 

En revanche, avec l’approche fondée sur la transmission parfaite, la liaison du 
tableau de const c h a r 1 6_t avec le paramètre du constructeur ne pose aucune difficulté. 
Il est ensuite transmis au constructeur de la donnée membre std : : stri ng de Person, 
et c’est à ce moment-là que l’incompatibilité entre la donnée passée par l’appelant (un 
tableau de const charl6_t) et ce qui est attendu (tout type accepté par le constructeur 
de std : : stri ng) est découverte. Le message d’erreur résultant risque d’être quelque 
peu impressionnant. Avec l’un des compilateurs que nous utilisons, il occupe plus de 
160 lignes. 

Dans cet exemple, la référence universelle est transmise une seule fois (depuis 
le constructeur de Person au constructeur de std : : stri ng), mais plus le système est 
complexe, plus une référence universelle traversera de multiples niveaux d’appels de 
fonctions avant d’arriver finalement au point où la validité des types des arguments est 
déterminée. Avec un nombre plus élevé de transmissions de la référence universelle, le 
message d’erreur risque fort d’être assez déroutant. De nombreux développeurs estiment 
que ce seul problème suffit à réserver les paramètres de type référence universelle aux 
interfaces qui exigent de bonnes performances. 

Dans le cas de Person, nous savons que le paramètre de type référence universelle 
de la fonction de transmission sert à l’initialisation d’un std : : stri ng. Nous pouvons 
donc utiliser static_assert pour vérifier qu’il peut jouer ce rôle. Le trait de type 
std : : i s_constructi bl e effectue un test à la compilation pour déterminer si un objet 
d’un type peut être construit à partir d’un objet (ou d’un ensemble d’objets) de type 
(ou d’un ensemble de types) différent. Il est donc facile d’écrire l’assertion : 


class Person 
publ 1c: 
templ ate< 
typename 
typename 
! std : :i 


I 

// Comme précédemment. 
T, 

= std: : e n a b 1 e_1 f _t < 

s_base_of<Person, std: :decay_t<T>>: :value 


&& 


! std : : i s_i ntegral <std: : remove_reference_t<T>>: :value 
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explicit Person(T&& n) 

: name(std: :forward<T>(n) ) 

I 

Il Confirmer qu’un std : : st ri ng peut être créé à partir d’un objet T. 
static_assert( 

std: :is_constructible<std: : string, T>: : value, 

"Le paramètre n ne peut pas servir à construire un std::string" 

): 


// Les actions du constructeur se font ici. 


// Suite de la classe Person (comme précédemment). 


-o 

n 


Le message d’erreur indiqué est affiché si le code client tente de créer un Person à 
partir d’un type qui ne peut pas servir à construire un std : : s tri ng. Malheureusement, 
dans cet exemple, stati c_assert se trouve dans le corps du constructeur, tandis que le 
code de transmission, qui fait partie de la liste d’initialisation du membre, le précède. 
Avec les compilateurs que nous utilisons, le joli message compréhensible généré par 
stati c_assert apparaît uniquement après les messages d’erreur habituels (après plus 
de 160 lignes). 


À retenir 

• Les alternatives à la combinaison des références universelles et de la surcharge 
sont l'emploi de noms de fonctions différents, le passage des paramètres sous 
forme de références Ivalue sur des const, le passage de paramètres par valeur 
et la mise en oeuvre du tog dispatching. 

• Contraindre les templates avec std : : enabl e_i f permet d'utiliser conjointement 
les références universelles et la surcharge, mais cela limite les conditions 
sous lesquelles le compilateur peut utiliser les surcharges sur les références 
universelles. 

• Les paramètres de type références universelles apportent souvent des avantages 
au niveau de l'efficacité, mais des inconvénients sur le plan de la facilité 
d'utilisation. 


CONSEIL N° 28 . COMPRENDRE LA RÉDUCTION 
DE RÉFÉRENCE 
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Le conseil 23 fait la remarque suivante : lorsqu’un argument est passé à une fonction 
template, le type déduit pour le paramètre du template encode le fait que l’argument 
est une Ivalue ou une rvalue. Elle oublie cependant de mentionner que cela ne se 
produit que si l’argument sert à l’initialisation d’un paramètre qui est une référence 
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universelle. 11 y a une bonne raison à cette omission : la présentation des références 
universelles n’arrive qu’au conseil 24. Prenons le template suivant et voyons ce que 
signifient ces observations sur les références universelles et l’encodage de l’information 
lvalue/rvalue : 


I templ ateCtypename T> 
void func(T&& param); 

Le type déduit pour le paramètre de template T indiquera si l’argument passé à 
param est une lvalue ou une rvalue. 

Le mécanisme d’encodage est simple. Lorsqu’une lvalue est passée en argument, 
le type déduit pour T est une référence lvalue. Lorsqu’une rvalue est transmise, T 
devient une non-référence. (Notez l’asymétrie : les lvalues sont encodées comme des 
références lvalue, tandis que les rvalues sont encodées comme des non-références.) 
Examinons le code suivant : 


Widget widgetFactory( ) ; 
Widget w; 
func(w) ; 

func(widgetFactory ( ) ) ; 


Il Fonction qui retourne une rvalue. 

Il Une variable (une lvalue). 

Il Appeler func avec une lvalue ; T est 
Il déduit de type Widget&. 

Il Appeler func avec une rvalue ; T est 
Il déduit de type Widget. 


Un Wi dget est passé dans les deux appels à func. Pourtant, puisque l’un des Wi dget 
est une lvalue et l’autre une rvalue, les types déduits pour le paramètre de template T 
sont différents. Nous le verrons plus loin, cela détermine si des références universelles 
deviennent des références rvalue ou des références lvalue, et sert de mécanisme sous- 
jacent au fonctionnement de std : : forward. 

Avant d’étudier en détail std : : forward et les références universelles, nous devons 
préciser que les références sur les références sont illégales en C++. Si nous tentons 
d’en déclarer une, le compilateur nous réprimande : 


int x; 

auto& & rx = x; // Erreur ! Une référence à une référence 
// est interdite. 

Voyons ce qui arrive lorsqu’une lvalue est passée à un template de fonction qui 
prend une référence universelle : 


tempi ate<typename T> 

void func(T&& param); // Comme précédemment. 


func(w) ; 


Il Invoquer func avec une lvalue ; 

Il le type déduit pour T est Widget&. 
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Si nous utilisons le type déduit pour T (c’est-à-dire Wi dget&) de façon à instancier 
le template, nous obtenons l’instruction suivante : 

void func(Widget& && param); 

Une référence à une référence ! Pourquoi le compilateur ne proteste-t-il pas ? 
Nous vous avons appris au conseil 24 que, en raison de l’initialisation de la référence 
universelle param avec une lvalue, le type de param est supposé être une référence 
lvalue, mais comment le compilateur fait-il pour partir du type déduit pour T et le 
remplacer dans le template par le suivant, afin d’obtenir cette signature finale pour la 
fonction ? 

void func(Widget& param); 

La réponse tient dans la réduction de référence (reference collapsing). C’est exact, 
il nous est interdit de déclarer des références à des références, mais le compilateur a 
le droit d’en générer dans des contextes spécifiques, notamment l’instanciation d’un 
template. Lorsque le compilateur génère des références à des références, la réduction 
de référence détermine ce qu’il advient ensuite. 

Puisqu’il existe deux sortes de référence (lvalue et rvalue), quatre combinaisons 
référence-référence sont possibles : lvalue sur lvalue, lvalue sur rvalue, rvalue sur lvalue 
et rvalue sur rvalue. Si une référence à une référence se trouve dans un contexte qui 
les autorise (par exemple au cours de l’instanciation d’un template), les références 
sont réduites en une seule référence conformément à la règle suivante : 

Si l’une des références est une référence lvalue, le résultat est une référence lvalue. 
Sinon, c’est-à-dire si les deux références sont des références rvalue, le résultat est 
une référence rvalue. 

Dans l’exemple précédent, la substitution du type déduit Wi dget& dans le template 
de f une génère une référence rvalue à une référence lvalue. La règle de réduction des 
références nous permet donc de savoir que le résultat est une référence lvalue. 

La réduction de référence est essentielle au fonctionnement de std: :forward. 
Comme l’explique le conseil 25, std : : f orwa rd est appliquée à des paramètres de type 
références universelles. Voici donc l’utilisation classique : 

| template<typename T> 
void f ( T&& fParam) 


// Faire quelque chose. 

someFuncistd: :forward<TXfParam) ) ; // Transmettre fParam à 

I // someFunc. 

Puisque fParam est une référence universelle, nous savons que le paramètre de type 
T indiquera si l’argument passé à f (c’est-à-dire l’expression utilisée pour initialiser 
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fParam) est une lvalue ou une rvalue. Le rôle de std: :forward est de convertir f Pa ram 
(une lvalue) en une rvalue si et seulement si T encode le fait que l’argument passé à f 
est une rvalue, autrement dit si T n’est pas un type référence. 

Voici une implémentation possible pour std : : forward : 


templ atettypename T> // Dans l’espace 

T&& forward(typename // de noms std. 

remove_reference<T> : :type& param) 

1 

return static_cast<T&&Xparam) ; 

I 


Elle n’est pas vraiment conforme à la norme (quelques détails d’interface ont été 
omis), mais ces différences n’ont pas d’intérêt pour comprendre le comportement de 
std: :forward. 

Supposonsque l’argument passé à f soit une lvalue de type Widget.Letypedéduitpour 
T sera W i d g e t & et l’appel à std:: forward va prendre la forme std: :forward<Widget&>. 
En insérant W i d g e t & dans l’implémentation de std: : forward, nous obtenons le code 
suivant : 

Widget& && forwardttypename 

remove_reference<Widget&>: :type& param) 

( return stati c_cast<Widget& &&Xparam); I 

Puisque le trait de type std :: remove_reference<Widget&> :: type donne Widget 
(voir le conseil 9), std: : forward devient : 

I Wi dget& && forward(Widget& param) 

( return stati c_cast<Wi dget& &&Xparam); I 

La réduction de référence est également appliquée au type de retour et à la 
conversion de type, ce qui donne la version finale suivante de std: : forward pour 
l’appel étudié : 


I Wi dget& forward(Widget& param) // Toujours dans l’espace 

I return static_cast<Widget&Xparam) ; I // de noms std. 

Vous le constatez, lorsqu’un argument lvalue est passé à la fonction template f, 
std : : forward est instancié de façon à prendre et à renvoyer une référence lvalue. La 
conversion de type qui se trouve dans std : : forward n’a pas d’incidence car param est 
déjà de type Wi dget& (le convertir en Wi dget& n’a aucun effet). Un argument lvalue 
passé à std : : forward va donc retourner une référence lvalue. Puisque, par définition, 
les références lvalue sont des lvalues, passer une lvalue à std : : forward provoque donc 
le retour d’une lvalue, exactement comme attendu. 

Supposons à présent que l’argument passé à f soit une rvalue de type Widget. Dans 
ce cas, le type déduit pour le paramètre de type T de f sera simplement Widget. L’appel à 
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std: :forward dans f correspondra donc à std: :forward<Widget>. Si nous remplaçons 
T parWidget dans l’implémentation de std: :forward, nous obtenons le code suivant: 

Widget&& forward(typename 

remove_reference<Widget>: :type& param) 

( return static_cast<Widget&&Xparam) : ) 

L’application de std: : remove_reference à Widget, qui n’est pas type référence, 
donne le type de départ (Widget). std: :forward devient donc : 

I Wi dget&& forward(Widget& param) 

I return static_cast<Widget&&Xparam) : ) 

Puisque ce code ne comprend aucune référence à une référence, la réduction de 
référence n’entre pas en scène et il correspond à la version finale de std: :forward 
instanciée pour l’appel. 

Les références rvalue renvoyées par des fonctions étant des rvalues, std : : f orwa rd 
va, dans ce cas, transformer le paramètre f Param (une lvalue) de f en une rvalue. Un 
argument rvalue passé à f sera finalement transmis à someFunc comme une rvalue, 
exactement comme attendu. 

En C++14, std : : remove_reference_t permet d’implémenter std::forward de 
façon plus concise : 

templ ate<typename T> // C++14 ; toujours dans 

T&& forward(remove_reference_t<T>& param) // l’espace de noms std. 

( 

return static_cast<T&&Xparam) : 
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La réduction de référence se produit dans quatre contextes. Le premier, et le plus 
courant, concerne l’instanciation de template. La génération de type pour les variables 
auto représente le deuxième. Le fonctionnement est essentiellement identique à 
celui déroulé pour les templates, car la déduction de type pour les variables auto es t 
fondamentalement identique à celle mise en place pour les template (voir le conseil 2). 
Reprenons cet exemple donné précédemment : 


templ ateCtypename T> 
void func(T&& param): 

Widget widgetFactory( ) ; 

Widget w; 

func(w) ; 

func(widgetFactory( ) ) ; 


// Fonction qui retourne une rvalue. 

// Une variable (une lvalue). 

// Appeler func avec une lvalue : T est 
// déduit de type Uidget&. 

Il Appeler func avec une rvalue ; T est 
Il déduit de type Midget. 
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Voyons ce qui se passe avec une variable auto. La déclaration 

auto&& wl = w; 

initialise wl à partir d’une lvalue, conduisant au type déduit W i d g e t & pour auto. En 
remplaçant auto par Widget& dans la déclaration de wl, nous obtenons un code qui 
comprend une référence à une référence : 

Widget& && wl = w; 

Suite à la réduction de référence, nous arrivons à : 

Widget& wl = w; 

Par conséquent, wl est une référence lvalue. 

La déclaration 

auto&& w2 = widgetFactory( ) ; 

initialise w2 à partir d’une rvalue, conduisant au type déduit Widget pour auto ; ce 
type déduit n’est pas une référence. En remplaçant auto par Wi dget, nous obtenons : 

Widget&& w2 = widgetFactory( ) ; 

Puisque cette ligne ne contient pas de référence à une référence, le traitement est 
terminé et w2 est une référence rvalue. 

Nous pouvons à présent vraiment comprendre les références universelles intro- 
duites au conseil 24. Une référence universelle n’est pas un nouveau genre de référence 
mais une référence rvalue dans un contexte où deux conditions sont satisfaites : 

• La déduction de type distingue les lvalues et les rvalues. Les Ivalues de type T 
ont pour type déduit T&, tandis que les rvalues de type T ont pour type déduit T. 

• La réduction de référence a lieu. 

Le concept de référence universelle est utile car il nous évite d’avoir à reconnaître 
l’existence de contextes de réduction des références, à déduire mentalement des types 
différents pour les lvalues et les rvalues, et à appliquer la règle de réduction de référence 
après avoir mentalement remplacé les types déduits dans les contextes concernés. 

Nous avons mentionné quatre contextes, mais n’en avons présentés que deux : 
instanciation de template et génération de type auto. Le troisième correspond à la 
génération et à l’utilisation de typedef et des déclarations d’alias (voir le conseil 9). Si, 
au cours de la création ou de l’évaluation d’un typedef, des références à des références 
surgissent, la réduction de référence intervient pour les éliminer. Supposons, par 
exemple, que nous ayons une classe template Widget qui comprend un typedef pour 
un type de référence rvalue : 
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templ ateCtypename T> 
class Widget { 
publ i c : 

typedef T&& Rval ueRefToT; 
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Supposons également que nous instanciions Widget avec un type de référence 
lvalue : 

Wi dget<i n t&> w; 

En remplaçant T par int& dans le template Widget, nous obtenons le typedef 
suivant : 

typedef i nt& && Rval ueRefToT; 

La réduction de référence arrive à : 

typedef i nt& Rval ueRefToT; 

Nous en concluons que le nom choisi pour le typedef n’est peut-être pas aussi 
adapté que nous l’espérions : Rval ueRefToT est un typedef pour une référence lvalue 
quand Wi dget est instancié avec un type qui correspond à une référence lvalue. 

Le dernier contexte d’application de la réduction de référence correspond aux 
utilisations de decl type. Si une référence à une référence apparaît au cours de l’analyse 
d’un type qui implique decl type, la réduction de référence va se charger de l’éliminer. 
(Pour de plus amples informations sur decl type, consulter le conseil 3.) 


À retenir 

• La réduction de référence intervient dans quatre contextes : instanciation de 
template, génération de type auto, création et utilisation de typedef et de 
déclarations d'alias, et utilisation de decl type. 

• Lorsque le compilateur génère une référence à une référence dans un contexte 
de réduction de référence, le résultat est une seule référence. Si l'une des 
références d'origine est une référence lvalue, le résultat est une référence lvalue. 
Sinon, il s'agit d'une référence rvalue. 

• Les références universelles sont des références rvalue dans les contextes où la 
déduction de type fait une différence entre les Ivalues et les rvalues, et où la 
réduction de référence se produit. 
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CONSEIL N° 29. SUPPOSER QUE LES OPÉRATIONS 
DE DÉPLACEMENT SONT ABSENTES, ONÉREUSES 
ET INUTILISÉES 

La sémantique de déplacement est peut-être bien la principale nouveauté de C+ + 1 1. 
Vous entendrez probablement certaines personnes dire que « Déplacer des conteneurs 
est à présent aussi efficace que copier des pointeurs ! » ou que « La copie d’objets 
temporaires est à présent tellement efficace que s’efforcer de l’éviter dans le code 
équivaut à une optimisation prématurée ! ». Ces analyses sont faciles à comprendre. 
La sémantique de déplacement est vraiment une fonctionnalité importante. Non 
seulement elle permet au compilateur de remplacer des opérations de copie onéreuses 
par des déplacements plus rapides, mais elle lui impose de procéder ainsi (lorsque les 
conditions d’application sont satisfaites). Prenez votre base de code C++98, soumettez- 
la à un compilateur C+ + 1 1 accompagné de la bibliothèque standard correspondante, 
et, pouf !, le logiciel s’exécute plus rapidement. 

La sémantique de déplacement permet réellement d’éviter des copies, ce qui l’a 
élevée au rang de légende. Cependant, les légendes découlent généralement d’une 
exagération. Dans ce conseil, notre objectif est de donner à vos attentes un certain 
réalisme. 

Observons tout d’abord que de nombreux types ne sont pas compatibles avec la 
sémantique de déplacement. L’intégralité de la bibliothèque standard de C++98 a été 
revue pour C++ 1 1 de façon à ajouter des opérations de déplacement aux types pour 
lesquels le déplacement pouvait être plus rapide que la copie. Les composants de la 
bibliothèque ont également été adaptés pour exploiter ces opérations. Toutefois, il est 
probable que la base de code manipulée n’ait pas été totalement refondue pour tirer 
parti de C++11. Pour les types de nos applications (ou des bibliothèques que nous 
utilisons) qui n’ont pas été remaniés pour C++1 1, la prise en charge du déplacement 
par le compilateur n’apportera pas grand-chose. Il est vrai que C+ + 1 1 est prêt à générer 
des opérations de déplacement pour les classes qui n’en disposent pas, mais cela ne 
concerne que les classes qui ne déclarent aucune opération de copie, opération de 
déplacement, ni destructeur (voir le conseil 17). Lorsqu’une donnée membre ou une 
classe de base a un type pour lequel le déplacement a été désactivé (par exemple 
en supprimant les opérations de déplacement ; voir le conseil 1 1 ), la génération des 
opérations de déplacement par le compilateur est également désactivée. Pour les types 
sans prise en charge explicite du déplacement et non éligibles aux opérations de 
déplacement générées par le compilateur, il n’y a aucune raison d’attendre de C+ + 11 
une amélioration des performances par rapport à C++98. 

Même les types qui prennent explicitement en charge le déplacement pourraient 
ne pas apporter autant de bénéfices qu’espéré. Par exemple, tous les conteneurs de 
la bibliothèque standard de C+ + 11 disposent des opérations de déplacement, mais 
il serait erroné de croire que le déplacement de n’importe quel conteneur se fait à 
faible coût. Pour certains d’entre eux, il est tout bonnement impossible de déplacer 
leur contenu sans payer un prix élevé. Pour d’autres, les opérations de déplacement 
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bon marché offertes posent des conditions que les éléments du conteneur ne peuvent 
pas remplir. 

Examinons le nouveau conteneur std: :array de C+ + 11. Fondamentalement, il 
équivaut à un tableau intégré doté d’une interface STL. Il est donc différent des 
autres conteneurs standard, qui stockent leur contenu sur le tas. Conceptuellement, 
les objets créés à partir de ces types de conteneurs comprennent, sous forme d’une 
donnée membre, uniquement un pointeur sur la zone de mémoire dans le tas qui sert 
à stocker leur contenu. (La réalité est plus complexe, mais cela n’a pas d’importance 
pour notre analyse.) Grâce à ce pointeur, il est possible de déplacer l’intégralité du 
contenu du conteneur en un temps constant : il suffit de copier le pointeur sur le 
contenu du conteneur depuis le conteneur source vers la cible et de fixer le pointeur 
initial à nul (figure 5.1) : 

vwl 

std: : vector<Widget> vwl; I i J 

// Ajouter des données à vwl. 

vwl 

// Déplacer vwl dans vw2. L’exécution 

Il se fait en un temps constant. 

Il Seuls des pointeurs dans vwl 

Il et dans vw2 sont modifiés. 

auto vw2 = std: :move( vwl ) ; 

Les objets std : : array n’ont pas un tel pointeur, car les données contenues dans 
un std: :array sont stockées directement dans l’objet std: :array (figure 5.2) : 



Figure 5.1 - Déplacement d'un 
conteneur par copie de pointeur. 


std: :array<Widget, 10000> awl; 
// Ajouter des données à awl. 


awl 

Widgets 


Il Déplacer awl dans aw2. 

Il L’exécution se fait en un temps 
Il linéaire. 

Il Tous les éléments de awl 
Il sont déplacés dans aw2. 
auto aw2 = std: :move(awl) ; 


awl 

Widgets (déplacés depuis) 

aw2 

Widgets (déplacés vers) 


Figure 5.2 - Déplacement d'un 
conteneur par copie de ses éléments. 


Les éléments de awl sont déplacés dans aw2. En supposant que Wi dget soit un type 
pour lequel le déplacement est plus rapide que la copie, déplacer un std: : array de 
Wi dget sera plus rapide que copier le même std : : array. Par conséquent, std : : array 
prend certainement en charge le déplacement. Cela dit, le déplacement et la copie 
d’un std: : array sont des opérations dont la complexité en temps est linéaire, car 
chaque élément du conteneur doit être copié ou déplacé. On est loin du « déplacement 
d’un conteneur à présent aussi efficace que l’affectation de deux pointeurs », comme 
peuvent le clamer certains. 
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Dans le cas de std: : string, les déplacements se font en temps constant et les 
copies en temps linéaire. Il semblerait donc que le déplacement soit plus rapide que la 
copie, mais ce n’est pas nécessairement le cas. De nombreuses implémentations des 
chaînes de caractères mettent en œuvre l 'optimisation des petites chaînes (SS O, small 
string optimization) , dans laquelle les chaînes de caractères « courtes » (par exemple 
celles dont la capacité ne dépasse pas 15 caractères) sont mémorisées dans un tampon 
à l’intérieur de l’objet std : : st ri ng ; aucun espace de stockage alloué sur le tas n’est 
utilisé. Dans une implémentation fondée sur la SSO, le déplacement de petites 
chaînes de caractères n’est pas plus rapide que leur copie, car l’astuce de la copie 
d’un seul pointeur qui avantage généralement les déplacements par rapport aux copies 
ne s’applique plus. 

La SSO repose sur le constat que les chaînes courtes sont très répandues dans 
la plupart des applications. En stockant ces chaînes de caractères dans un tampon 
interne, l’allocation dynamique d’une zone de mémoire n’est plus requise. Des gains de 
performance en découlent généralement. Mais les déplacements ne sont plus, dans ce 
cas, plus rapides que les copies. Toutefois, nous pouvons raisonner dans le sens inverse 
et considérer que les copies ne sont plus plus lentes que les déplacements. 

Même lorsque les types prennent en charge des opérations de déplacement rapides, 
il existe des situations où des copies sont effectuées alors que l’on imaginait assurément 
des déplacements. Le conseil 14 explique que certaines opérations des conteneurs de 
la bibliothèque standard apportent une garantie élevée sur la sécurité vis-à-vis des 
exceptions afin qu’un ancien code C++98 qui en dépend ne soit pas remis en question 
lors du passage à C++1 1. Les opérations de copie sous-jacentes sont alors remplacées 
par des opérations de déplacement uniquement si celles-ci sont assurées de ne pas lever 
d’exception. En conséquence, même si un type offre des opérations de déplacement 
plus efficaces que les opérations de copie correspondantes et même si, à un endroit 
particulier du code, une opération de déplacement serait normalement appropriée (par 
exemple si l’objet source est une rvalue), le compilateur peut être obligé d’invoquer une 
opération de copie car l’opération de déplacement correspondante n’est pas déclarée 
noexcept. 

Voici plusieurs scénarios dans lesquels la sémantique de déplacement de C+ + 1 1 
ne fait aucun bien : 

• Aucune opération de déplacement : l’objet à partir duquel se fait le déplace- 
ment ne propose aucune opération de déplacement. La demande de déplace- 
ment se transforme donc en demande de copie. 

• Le déplacement n’est pas plus rapide : l’objet à partir duquel se fait le 
déplacement offre des opérations de déplacement dont l’efficacité n’est pas 
supérieure à celle de ses opérations de copie. 

• Le déplacement n’est pas utilisable : le contexte dans lequel le déplacement 
devrait avoir lieu nécessite une opération de déplacement qui ne lève pas 
d’exception, mais cette opération n’est pas déclarée noexcept. 

11 existe également un autre scénario dans lequel la sémantique de déplacement 
n’apporte aucune amélioration : 
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• L’objet source est une lvalue : hormis de très rares exceptions (voir le 
conseil 25), seules des rvalues peuvent être employées comme source d’une 
opération de déplacement. 

Mais l’intitulé de ce conseil indique qu’il faut supposer que les opérations de 
déplacement sont absentes, onéreuses et inutilisées. C’est généralement le cas dans 
le développement d’un code générique, par exemple l’écriture de templates, car nous 
ne pouvons pas connaître tous les types manipulés. Dans de telles circonstances, nous 
devons être aussi prudents vis-à-vis de la copie des objets que nous l’étions en C++98, 
avant que la sémantique de déplacement n’existe. Cela concerne également le code 
« non stabilisé », c’est-à-dire celui dans lequel les caractéristiques des types utilisés 
font l’objet de modifications relativement fréquentes. 

Toutefois, nous connaissons très souvent les types utilisés dans notre code et nous 
pouvons supposer que leurs caractéristiques ne changent pas (par exemple que leurs 
opérations de déplacement ne sont pas onéreuses). Lorsque c’est le cas, oublions les 
suppositions et examinons simplement les détails de la prise en charge du déplacement 
pour les types employés. Si leurs opérations de déplacement sont efficaces et si nous 
utilisons les objets dans des contextes où ces opérations seront invoquées, nous 
pouvons compter sur la sémantique de déplacement pour remplacer les opérations de 
copie par les opérations de déplacement équivalentes moins onéreuses. 


À retenir 

• Supposer que les opérations de déplacement sont absentes, onéreuses et 
inutilisées. 

• Avec le code qui utilise des types connus ou qui prend en charge la sémantique 
de déplacement, ne faire aucune supposition. 
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La transmission parfaite est probablement l’une des fonctionnalités de C+ + 1 1 les plus 
annoncées. En y regardant de plus près, nous découvrons que, derrière la notion de 
parfait, il y a un idéal et une réalité. La transmission parfaite de C++1 1 est excellente, 
mais elle n’atteint la perfection que si nous sommes prêts à oublier un ou deux petits 
détails. Ce conseil a pour objectif de vous familiariser avec ces détails. 

Avant d’explorer ces détails, examinons ce que signifie « transmission parfaite ». 
La « transmission » intervient lorsqu’une fonction passe, transmet, ses paramètres à 
une autre. L’objectif est que la seconde fonction (la destination de la transmission) 
reçoive les objets reçus par la première fonction (la source de la transmission). Les 
paramètres passés par valeur sont donc exclus, car ils sont des copies des arguments 
passés par le code appelant. La fonction destinataire doit pouvoir manipuler les objets 
d’origine. Les paramètres de type pointeur sont également écartés, car nous ne voulons 
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pas imposer le passage de pointeurs au code appelant. Autrement dit, dans le contexte 
général de la transmission, les paramètres seront des références. 

La transmission parfaite signifie que nous ne voulons pas nous contenter de 
transmettre des objets mais également leurs caractéristiques essentielles : leur type, 
s’ils sont des lvalues ou des rvalues, et s’ils sont const ou vol ati 1 e. Puisque nous avons 
expliqué que les paramètres sont des références, cela implique que nous utiliserons 
des références universelles (voir le conseil 24). En effet, seuls les paramètres de type 
références universelles permettent de savoir si les arguments passés sont des lvalues ou 
des rvalues. 

Supposons que nous ayons une fonction f et que nous souhaitions écrire une 
fonction (en réalité un template de fonction) qui transmette ses paramètres à f. Voici 
le code de base correspondant : 

templ ate<typename T> 

void fwd(T&& param) // Accepter n’importe quel argument. 

I 

f(std: :forward<T>(param) ) ; // Le transmettre à f. 


Les fonctions de transmission sont, par nature, génériques. Par exemple, le template 
fwd accepte n’importe quel type d’argument et retransmet celui qu’il reçoit, quel qu’il 
soit. La généricité de ces fonctions peut être logiquement étendue en les écrivant 
comme des templates variadiques, c’est-à-dire acceptant un nombre quelconque 
d’arguments. Voici la version variadique de fwd : 


templ ate<typename. . . Ts> 

void fwd(Ts&&... params) // Accepter n’importe quels arguments. 

1 

f ( s td : :forward<Ts>( params). . . ) ; // Les transmettre à f. 

1 


C’est la forme que nous rencontrerons, entre autres, dans les fonctions de pla- 
cement (voir le conseil 42) et dans les fonctions fabriques de pointeurs intelligents, 
std: :make_shared et std: :make_unique (voir le conseil 21). 

Avec notre fonction cible f et notre fonction de transmission fwd, la transmission 
parfaite échoue si l’appel de f avec un argument spécifique effectue une certaine 
opération mais que l’appel de fwd avec le même argument en fait une autre : 


f( expression ); Il Si cet appel effectue une opération et 

fwd ( expression ); Il que celui-ci en réalise une autre, fwd ne 

Il transmet pas parfaitement expression à f. 


Plusieurs sortes d’arguments conduisent à un tel échec. Puisqu’il est important 
de les connaître et de savoir comment les contourner, passons en revue les sortes 
d’arguments incompatibles avec la transmission parfaite. 
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Supposons que f soit déclarée de la manière suivante : 

void f(const std: :vector<i'nt>& v); 

La compilation d’un appel de f avec un initialiseur à accolades ne pose pas de 
problème : 

I f ( { 1, 2, 3 }); // Parfait, "11, 2, 31" est implicitement 

// converti en std: : vector<int>. 

En revanche, si nous passons à fwd le même initialiseur à accolades, le code ne 
compile pas : 

fwd ( { 1, 2, 3 }); // Erreur ! La compilation échoue. 

En effet, l’utilisation d’un initialiseur à accolades représente l’un des cas d’échec 
de la transmission parfaite. 

Tous ces cas d’échec ont une cause commune. Dans un appel direct à f (comme 
dans f ( I 1 , 2 , 3 I )), le compilateur voit les arguments passés au point d’appel, ainsi que 
les types des paramètres déclarés par f. Il compare les arguments indiqués dans l’appel 
aux déclarations des paramètres afin de déterminer leur compatibilité. Si nécessaire, 
il effectue des conversions implicites pour que l’appel puisse se faire. Dans l’exemple 
précédent, il génère un objet std : : vectoKi nt> temporaire à partir de ( 1 , 2 , 3 } de 
sorte que le paramètre v de f dispose d’un objet std : : vector<i nt> auquel il puisse être 
lié. 

Lors d’un appel indirect à f au travers du template de fonction de transmission 
fwd, le compilateur ne compare plus les arguments passés depuis le point d’appel dans 
fwd aux déclarations de paramètres dans f . À la place, il déduit les types des arguments 
transmis à fwd et les compare aux déclarations de paramètres de f. La transmission 
parfaite échoue dans les deux situations suivantes : 

• Le compilateur ne parvient pas à déduire un type pour un ou plusieurs des 
paramètres de fwd. La compilation du code échoue alors. 

• Le compilateur déduit le « mauvais » type pour un ou plusieurs des paramètres 
de fwd. Dans ce contexte, « mauvais » peut signifier que l’instanciation de fwd 
avec les types déduits ne compilera pas, mais également que l’appel à f avec 
les types déduits de fwd aura un comportement différent d’un appel direct à f 
avec les arguments qui ont été passés à fwd. Ce comportement différent peut se 
produire lors d’une surcharge du nom de la fonction f . En raison d’une déduction 
de type « incorrect », la surcharge de f appelée dans fwd pourrait être différente 
de celle qui serait invoquée avec un appel direct de f . 

Dans l’appel « fwd ( { 1 , 2 , 3 } ) » précédent, le problème vient du fait que le 
passage d’un initialiseur à accolades à un paramètre de template de fonction qui 
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n’est pas déclaré std : -.initial i zer_l i st constitue, comme le définit la norme, « un 
contexte non déduit ». Autrement dit, dans l’appel à fwd, le compilateur n’a pas le 
droit de déduire un type pour l’expression { 1 , 2,3 ! car le paramètre de fwd n’est pas 
déclaré de type std : : i ni ti al i zer_l i st. Puisqu’il est dans l’incapacité de déduire un 
type pour le paramètre de fwd, le compilateur n’a d’autre choix que de rejeter l’appel. 

Il est intéressant de noter que, comme l’explique le conseil 2, la déduction 
de type fonctionne parfaitement pour les variables auto initialisées avec un ini- 
tialiseur à accolades. Puisque ces variables sont considérées comme des objets 
std : : i ni ti al i zer_l i st, nous disposons d’une solution simple pour les cas où le 
type déduit dans la fonction de transmission doit être std: : ini ti al i zer_l i st. Il 
suffit de déclarer une variable locale avec auto et de passer celle-ci à la fonction de 
transmission : 

auto il = I 1, 2, 3 ); //Le type déduit pour il 

// est std: : ini t i al izer_l ist<int> . 

fwd(il): // Transmission parfaite de il à f. 


0 ou NULL en tant que pointeurs nuis 

Le conseil 8 explique que si nous essayons de passer à un template un pointeur nul 
représenté par 0 ou NULL, la déduction de type va de travers et conduit non pas à un 
type pointeur mais à un type entier (en général un int) pour l’argument passé à la 
place. Par conséquent, ni 0 ni NULL ne permet une transmission parfaite en tant que 
pointeur nul. Mais le problème est facile à corriger, puisqu’il suffit de passer non pas 0 
ou NULL, mais nul 1 ptr. Les détails se trouvent dans le conseil 8. 

Données membres static const intégrales uniquement déclarées 

De façon générale, il est inutile de définir les données membres static const intégrales 
dans les classes, leur déclaration suffit. En effet, le compilateur effectue une propagation 
de const sur les valeurs de ces membres, ce qui permet d’éviter de leur réserver de la 
mémoire. Prenons par exemple le code suivant : 

class Widget I 
publ ic: 

static const std::size_t MinVals = 28; // Déclarer MinVals. 

I: 

// Aucune définition 
// pour MinVals. 

std: :vector<int> widgetData; 

widgetData . reserve(Widget: : Mi n Va 1 s ) : // Utiliser MinVals. 

Dans cet exemple, nous utilisons Widget: : MinVals (ci-après simplement noté 
Mi nVal s) pour préciser la capacité initiale de widgetData, même s’il n’existe aucune 
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définition de Mi n Val s. Le compilateur résout le problème de définition absente (comme 
il y est obligé) en mettant la valeur 28 partout où Mi nVal s est utilisé. Le fait qu’aucune 
zone de mémoire n’est réservée à la valeur de Mi n Val s ne pose pas de problème. Pour 
que l’adresse de MinVals puisse être prise (par exemple si le programmeur crée un 
pointeur sur MinVals), il faut qu’un espace de stockage soit réservé à Mi nVal s (afin que 
le pointeur puisse pointer sur quelque chose). Dans ce cas, le code précédent compile, 
mais l’édition de liens échoue car MinVals n’a pas été défini. 

Avec ces informations en tête, imaginons que f (la fonction à laquelle fwd transmet 
son argument) soit déclarée de la manière suivante : 

void f ( s td : :size_t val ) ; 

L’appel de f avec MinVals ne pose pas de problème, car le compilateur se contente 
de remplacer MinVals par sa valeur : 

f ( Wi dget : : Mi nVal s ) ; // Parfait, traité comme "f ( 28 ) " . 

Hélas, l’appel à f via fwd ne se passe pas aussi bien : 

fwd (Widget: :MinVals) ; // Erreur ! L'édition de liens doit échouer. 

La compilation de ce code réussit, mais son édition de liens doit échouer. Si cet 
exemple vous fait penser à ce qui se passe lorsque nous essayons de prendre l’adresse 
de Mi n Val s, vous avez raison, car le problème sous-jacent est identique. 

Certes, nous ne prenons pas l’adresse de MinVals dans le code source, mais le 
paramètre de fwd est une référence universelle et les références, dans le code généré 
par le compilateur, sont généralement traitées comme des pointeurs. Dans le code 
binaire qui correspond au programme (et au niveau matériel), les pointeurs et les 
références sont essentiellement la même chose. À ce niveau, les références peuvent 
être vues comme des pointeurs qui sont déréférencés automatiquement. Dans ces 
conditions, passer Mi nVal s par référence équivaut à passer cette variable au travers 
d’un pointeur, qui a donc besoin d’une zone de mémoire sur laquelle pointer. Par 
conséquent, pour passer des données membres stati c const intégrales par référence, 
nous devons généralement les définir et cette contrainte peut conduire à l’invalidité 
du code s’il utilise la transmission parfaite. 

Peut-être avez-vous remarqué les termes employés dans la discussion précédente. 
L’édition de liens « doit échouer ». Les références sont « généralement » considérées 
comme des pointeurs. Pour passer des données membres stati c const intégrales par 
référence, elles doivent « généralement » être définies. C’est comme si nous savions 
des choses que nous voulions cacher ... 

C’est bien le cas. Selon la norme, passer MinVals par référence exige que cette 
variable soit définie. Mais toutes les implémentations n’imposent pas cette contrainte. 
Par conséquent, en fonction de votre compilateur et de votre éditeur de liens, il 
est possible que vous puissiez transmettre parfaitement des données membres stati c 
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const intégrales sans les avoir définies. Dans ce cas, félicitations, mais il y a de bonnes 
raisons de penser qu’un tel code n’est pas portable. Pour qu’il le devienne, il suffit 
de définir la donnée membre stati c const intégrale en question. Par exemple, pour 

Mi nVal s : 

const std : : si ze_t Widget: :MinVals; // Dans le fichier .cpp de Widget. 

Notez que la définition ne reprend pas l’initialiseur (28, dans le cas de Mi nVal s), 
mais ne vous focalisez pas sur ce détail. En effet, si vous donnez l’initialiseur aux deux 
endroits, le compilateur vous préviendra et vous pourrez corriger votre code. 


Noms de fonctions surchargées et noms de templates 

Supposons que le comportement de notre fonction f (celle à laquelle nous transmet- 
tons des arguments via fwd) puisse être personnalisé en lui passant une fonction qui 
prend en charge une partie du travail. En imaginant que les paramètres et la valeur de 
retour de cette fonction soient des i nt, voici une déclaration de f : 

void f(int (*pf)(int)); // pf = "processing function". 

f pourrait également être déclarée avec une syntaxe plus simple, sans le pointeur. 
Cette déclaration, que voici, aurait le même sens que la précédente : 

void f(int pf(int)); // Déclarer la même fonction f. 

Quelle que soit la déclaration retenue, supposons à présent que nous ayons une 
fonction surchargée, processVal : 

I i nt processVal (int value); 
int processVal (int value, int priority); 

Nous pouvons passer processVal à f : 
f (processVal ) ; // Parfait. 

Mais cela est un peu surprenant, car f attend un pointeur sur une fonction, alors 
que processVal n’est pas un pointeur sur une fonction, ni même une fonction, mais le 
nom de deux fonctions différentes. Cependant, le compilateur est capable de savoir 
quelle processVal utiliser : celle qui correspond au type du paramètre de f. Il choisit 
donc la version de processVal qui prend un seul i nt et passe l’adresse de cette fonction 
àf. 

Cela fonctionne car la déclaration de f permet au compilateur de déterminer 
la version appropriée de processVal. En revanche, puisque fwd est un template de 
fonction, il ne dispose d’aucune information sur les types requis et il lui est impossible 
de déterminer la surcharge à employer ; 
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fwd(processVal ) ; Il Erreur ! Quelle processVal ? 

En soi, processVal n’a pas de type. Sans type il ne peut y avoir de déduction de 
type. Et sans déduction de type, nous avons un autre cas d’échec de la transmission 
parfaite. 

Nous rencontrons le même problème si nous tentons d’utiliser un template de 
fonction à la place (ou en plus) d’un nom de fonction surchargée. Un template de 
fonction représente non pas une mais plusieurs fonctions : 


templ ateCtypename T> 

T workOnVaKT param) Il Template pour traiter les valeurs. 

( ... 1 

f wd ( wor kOnVal ) ; Il Erreur ! Quelle instanciation de 

Il workOnVal ? 

Pour qu’une fonction de transmission parfaite comme fwd accepte un nom de 
fonction surchargée ou un nom de template, nous devons préciser manuellement la 
surcharge ou l’instanciation vers laquelle doit se faire la transmission. Par exemple, 
nous pouvons créer un pointeur de fonction du même type que le paramètre de f, 
initialiser ce pointeur avec processVal ou workOnVal (ce qui sélectionne la bonne 
version de processVal ou génère l’instanciation appropriée de workOnVal ) et passer le 
pointeur à fwd : 


T3 

O 


using ProcessFuncType = 

Int (*)(int); 

ProcessFuncType processVal Ptr = processVal; 
fwd(processVal Ptr) ; 

fwd(static_cast<ProcessFuncType>(workOnVal )) ; 


// Faire un typedef ; 

// voir le conseil 9. 

// Spécifier la signature 
Il requise pour processVal. 

Il Parfait. 

Il Également parfait. 


Bien entendu, cette solution impose que nous connaissions le type du pointeur de 
fonction vers lequel fwd effectue sa transmission. On peut raisonnablement supposer 
qu’une fonction de transmission parfaite fournira cette information. En effet, ces 
fonctions sont conçues pour accepter n’importe quoi et si aucune documentation ne 
nous indique quoi passer, comment pourrions- nous le savoir ? 


© 
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Champs de bits 

Le dernier cas d’échec de la transmission parfaite concerne l’utilisation d’un champ de 
bits en argument d’une fonction. Pour comprendre ce que cela signifie dans la pratique, 
examinons la représentation suivante d’un en-tête IPv4' : 


struct IPv4Header I 
std: :uint32_t version:4, 

I HL : 4 , 

DSCP: 6, 

ECN:2, 

total Length:16; 


Si notre fonction f (l’éternelle cible de notre fonction de transmission fwd) est 
déclarée avec un paramètre de type std: :size_t, son appel avec, par exemple, le 
champ total Length d’un objet IPv4Header ne va causer aucun tracas au compilateur : 

voi d f (std: :size_t sz); // Fonction à appeler. 

IPv4Header h; 

f(h. total Length) ; // Parfait. 

En revanche, si nous essayons de transmettre h . total Length à f par l’intermédiaire 
de fwd, le résultat est assez différent : 

fwd ( h . total Length) ; // Erreur ! 

Le problème vient du fait que le paramètre de fwd est une référence et que 
h . total Length est un champ de bits non const. On pourrait penser que tout va bien, 
mais la norme C++ interdit cette combinaison de façon inhabituellement claire : 
« Une référence non const ne doit pas être liée à un champ de bits. » Il existe une très 
bonne raison à cette interdiction. En effet, les champs de bits peuvent être constitués 
de parties quelconques des mots machine (par exemple les bits 3 à 5 d’un int sur 
32 bits), mais il n’existe aucune manière d’adresser directement de tels éléments. 
Nous avons mentionné précédemment que, au niveau matériel, les références et les 
pointeurs sont équivalents. Puisqu’il n’existe aucune manière de créer un pointeur 
sur des bits quelconques (C++ stipule que le char est le plus petit élément sur lequel 
nous pouvons pointer), il n’existe aucune solution pour lier une référence à des bits 
quelconques. 

Il est très facile de contourner l’impossibilité de transmission parfaite d’un champ 
de bits, mais il faut tout d’abord savoir qu’une fonction qui accepte un champ de bits 


1 . Nous supposons que ces champs de bits commencent par le bit le moins significatif et se terminent 
par le bit le plus significatif. C++ n’offre pas cette garantie, mais le compilateur propose souvent un 
mécanisme qui permet aux programmeurs de fixer l’agencement d’un champ de bits. 
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en argument reçoit une copie de la valeur du champ de bits. En effet, aucune fonction 
ne peut lier une référence à un champ de bits, pas plus qu’elle ne peut accepter 
des pointeurs sur des champs de bits puisque ceux-ci n’existent pas. Les champs de 
bits ne peuvent être passés qu’à des paramètres par valeur et, plus intéressant, à des 
références sur const. Dans le cas des paramètres par valeur, la fonction appelée reçoit 
évidemment une copie de la valeur d’un champ de bits. Dans le cas d’un paramètre de 
type référence sur const, la norme impose que la référence soit liée à une copie de la 
valeur du champ de bits stockée dans un objet de type intégral standard (par exemple 
un int). Les références sur const ne sont pas liées à des champs de bits mais à des 
objets « normaux » dans lesquels les valeurs des champs de bits ont été copiées. 

Pour passer un champ de bits à une fonction de transmission parfaite, il suffit 
d’exploiter le fait que la fonction cible recevra toujours une copie de la valeur de 
ce champ. Nous pouvons effectuer la copie nous-mêmes et la passer à la fonction 
de transmission. Dans le cas de notre exemple avec IPv4Header, voici le code 
correspondant : 


// Copier la valeur du champ de bits ; voir le conseil 6 

// pour des infos sur l’initialisation. 

auto length = static_cast<std: : ui ntl6_t>( h . total Length) ; 

fwd(length); // Transmettre la copie. 


En résumé 

Dans la plupart des cas, la transmission parfaite se passe exactement comme prévu. 
Il est inutile de s’en préoccuper. En revanche, lorsqu’elle échoue, c’est-à-dire lorsque 
du code semble-t-il convenable ne compile pas ou, pire, compile mais n’affiche pas le 
comportement attendu, il est important de connaître ses imperfections. Et il est tout 
aussi important de savoir comment les contourner. En général, la solution n’a rien de 
compliqué. 


À retenir 

• La transmission parfaite échoue lorsque la déduction de type de template échoue 
ou lorsque le type déduit est erroné. 

• Les sortes d'arguments qui conduisent à l'échec de la transmission parfaite sont : 
les initialiseurs à accolades, les pointeurs nuis représentés par 0 ou NULL, les 
données membres const static intégrales uniquement déclarées, les noms de 
templates et de fonctions surchargées, et les champs de bits. 


Copyright © 2016 Dunod. 
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A — 

Expressions lambda 


En programmation C++, les expressions lambda changent la donne. Cela vous surprend 
sans doute, car elles n’apportent au langage aucune nouvelle puissance d’expression. 
Tout ce qui est possible avec une expression lambda l’est en procédant manuellement, 
avec un travail de saisie plus important. Mais les expressions lambda sont tellement 
commodes pour créer des objets fonctions que l’impact sur le développement quotidien 
en C++ est énorme. Sans les expressions lambda, les algorithmes « _i f » de la STL (par 
exemple std : : fi nd_i f , std : : remove_i f, std : : count_i f, etc.) sont souvent utilisés 
avec des prédicats très simples. En revanche, lorsque les expressions lambda sont 
disponibles, leurs emplois avec des conditions complexes fleurissent. Il en va de 
même avec les algorithmes personnalisables par des fonctions de comparaison (par 
exemple std: : sort, std: :nth_element, std: : 1 ower_bound, etc.). En dehors de la STL, 
les expressions lambda permettent de créer aisément des supprimeurs personnalisés 
pour std: :unique_ptr et std: :shared_ptr (voir les conseils 18 et 19). Elles facilitent 
également la spécification des prédicats pour les variables de condition dans l’API des 
threads (voir le conseil 39). Sorties de la bibliothèque standard, les expressions lambda 
simplifient la spécification à la volée de fonctions de rappel, de fonctions d’adaptation 
de l’interface et de fonctions contextuelles pour les appels exceptionnels. Grâce aux 
expressions lambda, C++ est un langage de programmation encore plus agréable. 

Le jargon associé aux expressions lambda peut se révéler quelque peu perturbant. 
Voici quelques rappels : 

• Une expression lambda n’est rien d’autre qu’une expression. Elle fait partie du 
code source. Dans le code suivant, 
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std: :fi nd_if( conta /ner.begin( ) , container. end ( ) , 

[](int val) { return 0 < val && val < 10; }); 

l’expression mise en exergue est l’expression lambda. 
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• Une fermeture est l’objet d’exécution créé par une expression lambda. En 
fonction du mode de capture, les fermetures détiennent des références sur 
les données capturées, ou des copies de celles-ci. Dans l’appel précédent à 
std : : fi nd_i f , la fermeture correspond à l’objet passé en troisième argument à 
std : : fi nd_i f au moment de l’exécution. 

• Une classe de fermeture est une classe à partir de laquelle une fermeture est 
instanciée. Pour chaque expression lambda, le compilateur génère une classe 
de fermeture unique. Les instructions de l’expression lambda deviennent des 
instructions exécutables dans les fonctions membres de la classe de fermeture. 

En général, une expression lambda sert à créer une fermeture utilisée uniquement 
en argument d’une fonction. C’est le cas dans l’appel précédent à std : : fi nd_i f . 
Cependant, les fermetures peuvent souvent être copiées et nous pouvons donc avoir 
plusieurs fermetures dont le type correspond à une seule expression lambda. En voici 
un exemple : 

I 


int ; 

x; 


II 

X 

est 

une variable 

locale 

auto 

cl = 


II 

cl 

est 

une copie de 

1 a 

[X 

](int 

y) i return x * y > 55 ; 1 ; 

II 

fermeture produite 

par 




II 

1 f 

expression lambda 


auto 

c2 = 

cl ; 

II 

c2 

est 

une copie de 

cl. 

auto 

c3 = 

c2 ; 

II 

c3 

est 

une copie de 

c2. 


cl, c2 et c3 sont des copies de la fermeture générée par l’expression lambda. 

De façon informelle, nous pouvons parfaitement rendre un peu floue la séparation 
entre les expressions lambda, les fermetures et les classes de fermetures. Mais, dans les 
conseils qui suivent, il sera souvent important de distinguer ce qui existe au moment 
de la compilation (expressions lambda et classes de fermetures) et ce qui existe au 
moment de l’exécution (fermetures), ainsi que les relations entre chaque concept. 


CONSEIL N° 31. ÉVITER LES MODES DE CAPTURE 
PAR DÉFAUT 

Il existe deux modes de capture par défaut en C+ + 11 : par référence et par valeur. 
La capture par référence par défaut peut conduire à des références dans le vide. La 
capture par valeur par défaut nous attire car nous pensons être immunisés contre ce 
problème (ce n’est pas le cas) et nous donne le faux sentiment que nos fermetures sont 
indépendantes (ce n’est pas forcément le cas). 
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Voilà en substance la synthèse de ce conseil. Mais si votre penchant pour la 
technique ne se satisfait pas de ce résumé et exige des informations complémentaires, 
commençons par examiner les dangers de la capture par référence par défaut. 

Avec une capture par référence, la fermeture contient une référence à une variable 
locale ou à un paramètre, dont la disponibilité correspond à la portée dans laquelle 
l’expression lambda est définie. Si la durée de vie de la fermeture créée à partir de cette 
expression lambda dépasse celle de la variable locale ou du paramètre, la référence 
présente dans la fermeture va pendouiller. Par exemple, supposons que nous disposions 
d’un conteneur de fonctions de filtrage, chacune prenant un i nt et retournant un bool 
qui indique si la valeur passée convient au filtre : 


using Fi 1 terContainer = 
std: :vector<std: :function<bool ( i nt )>> ; 


// Voi r le conseil 9 pour 
// "using", le conseil 2 
// pour std: rfunction. 


Fi 1 terContainer filters; 


// Fonctions de filtrage. 


Nous pouvons ajouter un filtre pour les multiples de 5 : 


filters.emplace_back( // Voir le conseil 42 

[ ] ( i n t value) f return value % 5 == 0; I // pour des infos sur 
); Il emplace_back. 


En réalité, le calcul du diviseur doit se faire au moment de l’exécution et nous ne 
pouvons donc pas figer simplement la valeur 5 dans l’expression lambda. L’ajout du 
filtre se fait alors de la manière suivante : 


T3 

O 


void addDivisorFiltert ) 

I 

auto calcl = computeSomeValueK ) : 
auto calc2 = computeSomeVal ue2( ) ; 

auto divisor = computeDi visor(cal cl , cal c2 ) ; 

Danger ! 

La référence à 
divisor va 
pendouiller ! 


filters.emplace_back( // 

[&](int value) I return value l divisor == 0: I II 
): Il 

II 


Ce code cache un problème qui n’attend que de se révéler. L’expression lambda fait 
référence à la variable locale di vi sor, mais celle-ci cesse d’exister dès que la fonction 
addDi vi sorFi 1 ter est terminée. Cela se produit immédiatement après l’exécution de 
fi 1 ter s . empl ace_back et la fonction ajoutée à fi 1 ters est essentiellement tuée dans 
l’œuf. 

Le même problème existerait si la capture par référence de di vi sor était explicite : 
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fil ters.empl ace_back( 

[&divisor](int value) Il Danger ! La référence 

( return value 1 divisor = 0; ) //à divisor va encore 

); Il pendouiller ! 

Toutefois, avec une capture explicite, il est plus facile de constater que la viabilité 
de l’expression lambda dépend de la durée de vie de di vi sor. Par ailleurs, la saisie du 
nom « divisor » nous incite à vérifier que di vi sor a une durée de vie au moins aussi 
longue que les fermetures de l’expression lambda. Cet aide-mémoire est plus précis que 
l’avertissement « vérifiez que rien ne pointe dans le vide » communiqué par « [&] ». 

Si nous savons qu’une fermeture sera employée immédiatement (par exemple en 
étant passée à un algorithme STL) et qu’elle ne sera pas copiée, les références qu’elle 
contient ne vivront pas plus longtemps que les variables locales et les paramètres 
de l’environnement dans lequel son expression lambda est créée. Dans ce cas, nous 
pourrions estimer que le risque de référence dans le vide n’existe pas et qu’il n’y 
a aucune raison d’éviter le mode de capture par référence par défaut. Par exemple, 
notre expression lambda de filtrage peut être utilisée uniquement en argument de 
l’algorithme std: :all_of de C++11, qui indique si tous les éléments de la plage 
spécifiée satisfont à une condition : 


templ ate<typename C> 

void workWithContainer(const C& container) 


auto calcl = computeSomeVal uel( ) ; 
auto calc2 = computeSomeVal ue2( ) ; 


// Comme précédemment. 
// Comme précédemment. 


auto divisor = computeDi visor(cal cl , calc2); // Comme précédemment. 


using ContElemT = typename C: : val ue_type; 


// Type des éléments 
// dans le conteneur. 


using std: : begi n ; 
using std: : end ; 

if ( std : : al l_of ( 

begin(container) , end(contai 
[&] (const ContElemTS value) 

( return value % divisor == 

) ( 

I else 1 
I 



II 

Pour 

la généri cité ; 


II 

voi r 

le conseil 13. 


II 

Si toutes les valeurs 

ner) , 

II 

dans 

container sont 


II 

des multiples du 

0; 1) 

II 

di vi seur. . . 


II 

C’est 

le cas . . . 


II 

Au moins une ne 


II 

l 'est 

pas . . . 


Oui ce code est sûr, mais sa sécurité est quelque peu précaire. S’il s’avérait que 
l’expression lambda pouvait être utile dans d’autres contextes (par exemple en tant 
que fonction ajoutée au conteneur filters) et qu’elle était copiée-collée dans un 
contexte où sa fermeture survivrait à divisor, nous reviendrions au problème de 


Conseil n° 31. Éviter les modes de capture par défaut 

référence dans le vide et rien dans la clause de capture ne nous rappellerait qu’une 
analyse de la durée de vie de di vi sor est nécessaire. 

Les bonnes pratiques conseillent donc de recenser explicitement les variables 
locales et les paramètres dont dépend une expression lambda. 

En C++14, nous pouvons employer auto dans les spécifications des paramètres 
des expressions lambda et ainsi simplifier le code précédent. Le typedef ContEl emT est 
retiré et la condition du i f est revue : 

if (std: :al l_of (begin(container) , end(container) , 

[&] ( const auto& value) // C++14. 

i return value % divisor == 0; I)) 

Pour résoudre notre problème lié à di vi sor, une solution pourrait être d’opter pour 
le mode de capture par valeur par défaut. Dans ce cas, l’ajout de l’expression lambda à 
fi 1 ter s se ferait de la manière suivante : 

filters.emplace_back( // À présent, 

[=] ( i nt value) { return value 1 divisor = 0; 1 II divisor ne 

); Il peut pas 

Il pendouiller. 

Si cela convient dans cet exemple, la capture par valeur par défaut n’est pas, 
de façon générale, le remède anti-pendouillement que nous pouvons imaginer. Le 
problème vient du fait que nous capturons un pointeur par valeur, le copions dans les 
fermetures issues de l’expression lambda, mais n’empêchons pas le code extérieur à 
l’expression lambda d’invoquer del ete sur le pointeur et donc de faire que notre copie 
pendouille. 

Vous pourriez prétendre que cela ne se produira jamais car, après avoir lu le 
chapitre 4, vous ne jurez plus que par les pointeurs intelligents et que seuls les 
mauvais programmeurs C++98 emploient des pointeurs bruts et del ete. Sans doute 
mais peu importe car, en réalité, vous utilisez des pointeurs bruts, qui peuvent être 
passés à del ete pour votre compte. C’est simplement qu’avec votre style moderne de 
programmation en C++, le code source ne le dévoile guère. 

Supposons que les Wi dget puissent ajouter des entrées au conteneur de filtres : 

class Widget { 
publ i c : 

// Constructeurs, etc. 

void addFilterO const; // Ajouter une entrée aux filtres, 

private: 

Int divisor; // Utilisé dans le fil ter du Widget. 

1; 

Voici comment nous pouvons définir Wi dget: : addFi 1 ter : 
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void Widget : : add Fi 1 te r ( ) const 
( 

filters.emplace_back( 

[=](int value) I return value % divisor == 0; I 

); 


Pour le non-initié béat, ce code semble parfaitement sûr. L’expression lambda 
dépend bien de di vi sor, mais le mode de capture par valeur par défaut fait en sorte 
que divisor est copié dans tous les fermetures issues de cette expression lambda. 

Faux, archi faux, horriblement faux, définitivement faux. 

Les captures s’appliquent uniquement aux variables locales non stati c (y compris 
les paramètres) visibles dans la portée dans laquelle l’expression lambda est créée. 
Dans le corps de Widget: raddFilter, divisor est non pas une variable locale mais 
une donnée membre de la classe Widget qui ne peut donc pas être capturée. Si nous 
retirons le mode de capture par défaut, le code ne compile toujours pas : 


void Widget: : addFi 1 ter ( ) const 
{ 

filters.emplace_back( // Erreur ! 

[ ] ( i n t value) I return value % divisor = 0; } Il divisor n’est 
): Il pas disponible. 


Par ailleurs, si nous tentons de capturer explicitement divisor (que ce soit par 
valeur ou par référence), le code ne compile pas car di vi sor n’est pas une variable 
locale ni un paramètre : 


void Widget: :addFil ter( ) const 
( 

fil ter s .empl ace_back( 

[divisor](int value) // Erreur ! Aucune variable locale 

( return value % divisor == 0: I II divisor à capturer. 

): 

I 


Si la clause de capture par valeur par défaut ne capture pas divisor, et malgré 
l’absence de la clause de capture par valeur par défaut, pourquoi le code ne compile-t-il 
pas ? 

L’explication tient dans l’utilisation implicite d’un pointeur brut : this. Toute 
fonction membre non stati c possède un pointeur this, utilisé chaque fois que nous 
mentionnons une donnée membre de la classe. Par exemple, dans n’importe quelle 
fonction membre de Wi dget, le compilateur remplace les utilisations de di vi sor par 
thi s - > d i vi sor. Examinons la version de Widget: : addFi 1 ter avec une capture par 
valeur par défaut : 
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void Widget: :addFilter( ) const 
I 

fi 1 ters .empl ace_back( 

[=](int value) I return value % divisor == 0; 1 

); 


Dans ce cas, la capture concerne non pas divisor mais le pointeur thi s de Widget. 
Le compilateur considère que le code est écrit ainsi : 


void Widget: : a d d F i 1 ter( ) const 
I 

auto currentObjectPtr = this; 

fi 1 ters .empl ace_back( 

[currentObjectPtr](int value) 

I return value % currentObjectPtr->di vi sor == 0; 1 

): 


Si nous comprenons cela, nous comprenons que la viabilité des fermetures issues de 
cette expression lambda est liée à la durée de vie du Widget dont elles contiennent une 
copie du pointeur this. Examinons le code suivant qui, en accord avec le chapitre 4, 
utilise uniquement des pointeurs intelligents : 


T3 

n 
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using FilterContainer = Il Comme précédemment, 

std: :vector<std: :function<bool (int)»; 


FilterContainer fil ters; Il Comme précédemment, 

void doSomeWorki ) 


auto pw = 

std: :make_unique<Widget>( ) ; 


Il Créer un Widget ; voir 
Il le conseil 21 pour 
Il std: :make_unique. 


pw->addFi 1 ter( ) ; Il Ajouter un filtre qui 

Il utilise Widget: :di visor. 

Il Détruire le Widget ; fil ters 
Il contient un pointeur dans le vide ! 


Lors d’un appel à doSomeWork, nous créons un filtre qui dépend de l’objet Widget 
produit par std: : ma ke_uni que, c’est-à-dire un filtre qui contient une copie d’un poin- 
teur sur ce Widget ; il s’agit du pointeur thi s du Widget. Ce filtre est ajouté à fi 1 ters, 
mais à la terminaison de doSomeWork, le Widget est détruit par le std: :unique_ptr qui 
gère son cycle de vie (voir le conseil 18). À partir de ce moment-là, fi 1 ters contient 
une entrée avec un pointeur dans le vide. 

Pour résoudre, ce problème précis, il suffit d’effectuer une copie locale de la donnée 
membre à capturer et de capturer cette copie à la place : 
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void Widget: : add Fl 1 ter( ) const 

1 



1 

auto divisorCopy = divisor; 

II 

Copier la donnée membre 

filters.emplace_back( 



[divisorCopy](int value) 

II 

Capturer la copie. 

1 return value 1 divisorCopy == 0; ) 

II 

Utiliser la copie. 


Pour être honnête, la capture par valeur par défaut fonctionne également avec 
cette approche : 


void Widget: : a d d F 1 1 te r ( ) const 
( 

auto divisorCopy = divisor; 

filters.emplace_back( 

[=](int value) 

( return value % divisorCopy == 0; 

I , 


Il Copier la donnée membre. 


Il Capturer la copie. 
Il Utiliser la copie. 


Mais pourquoi tenter le sort ? Avec un mode de capture par défaut, nous risquons 
de capturer thi s par mégarde, alors que nous pensions capturer divisor. 

En C+ + 14, pour capturer une donnée membre, une meilleure solution consiste à 
employer une capture généralisée (voir le conseil 32) : 

void Widget: : a d d F i 1 ter ( ) const 
I 

filters.emplace_back( // C++14 : 

[divisor = divisor](int value) // Copier divisor dans la fermeture. 

{ return value % divisor == 0; I II Utiliser la copie. 

): 


Puisque le mode de capture par défaut n’existe pas dans une capture généralisée, 
même en C++ 14, ce conseil 31 reste valable : il faut éviter les modes de capture par 
défaut. 

Les captures par valeur par défaut ont un autre inconvénient : elles peuvent 
suggérer que les fermetures correspondantes sont indépendantes et non touchées par 
les modifications des données effectuées à l’extérieur des fermetures. En général, c’est 
faux, car des expressions lambda peuvent dépendre non seulement de variables locales 
et de paramètres (qui peuvent être capturés), mais également d’objets ayant une durée 
de stockage statique. De tels objets sont définis dans une portée globale ou un espace de 
noms, ou sont déclarés à l’intérieur de classes, de fonctions ou de fichiers. Ils peuvent 
être employés dans des expressions lambda, mais ils ne peuvent pas être capturés. 
Pourtant, la spécification d’un mode de capture par valeur par défaut peut donner 
l’impression qu’ils le sont. Etudions une version revue de la fonction a d d D i v i sorFi 1 ter 
précédente : 
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I void addDi visorFi 1 ter( ) 

I 

static auto calcl = computeSomeValueK ) ; Il A présent static. 

static auto calc2 = computeSomeVal ue2( ) ; Il À présent static. 

static auto divisor = //À présent static. 

computeDivisor(calcl, cal c2 ) ; 

filters.emplace_back( 

[=] ( i nt value) // Rien n’est capturé ! 

I return value % divisor == 0; 1 II Référence au static précédent. 

); 

++divisor; Il Modifier divisor. 

1 

Nous pourrions pardonner au lecteur occasionnel d’un tel code qui voit « [=] » 
et qui en déduit que l’expression lambda effectue une copie de tous les objets qu’elle 
utilise et qu’elle est donc indépendante. Mais c’est faux. Puisque cette expression 
lambda n’utilise aucune variable locale non statique, rien n’est capturé. À la place, 
le code de l’expression lambda fait référence à la variable static divisor. Lorsque, 
au terme de chaque invocation de addDi vi sorFi 1 ter, di vi sor est incrémenté, toutes 
les expressions lambda qui ont été ajoutées à fi 1 ter s via cette fonction auront un 
nouveau comportement (qui correspond à la nouvelle valeur de divisor). D’un point 
de vue pratique, cette expression lambda capture divisor par référence, en totale 
contradiction avec ce que la clause de capture par valeur par défaut semble impliquer. 
En nous tenons loin des clauses de capture par valeur par défaut, nous évitons tout 
risque de lecture erronée de notre code. 


À retenir 

• La capture par référence par défaut peut conduire à des références dans le vide. 

• La capture par valeur par défaut peut conduire à des pointeurs dans le vide 
(en particulier this) et fait croire, à tort, que les expressions lambda sont 
indépendantes. 


CONSEIL N° 32. UTILISER DES CAPTURES GÉNÉRALISÉES 
POUR DÉPLACER DES OBJETS DANS DES FERMETURES 
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Dans certains cas, la capture par valeur ou par référence ne convient pas. Si nous 
avons un objet réservé au déplacement (par exemple un std : : unique_ptr ou un 
std: : future) que nous souhaitons utiliser dans une fermeture, C+ + 11 n’offre aucune 
solution. Si le coût de la copie d’un objet est élevé alors que celui de son déplacement 
est faible (par exemple la plupart des conteneurs de la bibliothèque standard), et si 
nous souhaitons utiliser cet objet dans une fermeture, il vaut mieux le déplacer que le 
copier. Mais C+ + 1 1 n’apporte toujours aucune réponse à ce besoin. 
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En C++ 14, la situation est différente. Cette version du langage prend directement 
en charge le déplacement des objets dans des fermetures. Si vous utilisez un compi- 
lateur C++ 14, réjouissez- vous et poursuivez votre lecture. Sinon, vous pouvez quand 
même vous réjouir et poursuivre votre lecture car des solutions en C+ + 11 existent 
pour s’approcher de la capture par déplacement. 

L’absence de la capture par déplacement a été reconnue comme une lacune même 
au moment de l’adoption de C+ + 1 1. Le remède simple aurait été de l’ajouter dans 
C++ 14, mais le comité de normalisation a choisi une voie différente. Il a introduit 
un nouveau mécanisme de capture tellement souple que la capture par déplacement 
ne représente que l’une de ses possibilités. Cette nouvelle capacité est appelée capture 
généralisée ( mit capture). Elle offre essentiellement les mêmes possibilités que les 
différentes formes de capture de C+ + 1 1, et plus encore. Toutefois, la seule exception 
concerne l’utilisation d’un mode de capture par défaut. Mais, cela n’a pas d’importance 
car le conseil 31 explique qu’il est préférable de les éviter. (Pour des situations 
équivalentes, la syntaxe de la capture généralisée est plus verbeuse que celle des 
captures C++ 1 1. Par conséquent, si une capture C+ + 1 1 convient à l’opération, il ne 
faut pas hésiter à l’utiliser.) 

Grâce à une capture généralisée, nous pouvons spécifier : 

1. le nom d’une donnée membre dans la classe de fermeture générée à partir de 
l’expression lambda, et 

2. une expression d’initialisation de cette donnée membre. 

Voici comment employer une capture généralisée pour déplacer un 
std : : uni que_ptr dans une fermeture : 


cl ass Widget I // Un type utile, 

publ ic: 


bool isVal i da ted ( ) const; 
bool isProcessed( ) const; 
bool isArchivedO const; 

pri vate: 


auto pw = std : : ma ke_un ique<Widget>( ) ; // Créer un Widget ; voir le 

// conseil 21 pour des infos 
// sur std: :make_unique. 


// Configurer *pw. 

auto func = [pw = std: :move(pw)] // Initialiser une donnée 

{ return pw ->isVal idated( ) // membre dans la fermeture 

&& pw->isArchi ved( ) ; I; // avec std: :move(pw) . 


Conseil n° 32. Utiliser des captures généralisées pour déplacer des objets dans des fermetures 



TJ 

O 

c 

3 

Û 

<£> 

t-H 

O 

<N 

© 


en 


>* 

CL 

O 


U 


'<U 

*73 

fi 

3 


U 

3 

TD 


D 

I 

*73 

fi 

G 

© 


Le code mis en exergue correspond à la capture généralisée. Nous trouvons, à 
gauche du signe « = », le nom de la donnée membre dans la classe de fermeture 
spécifiée et, à sa droite, l’expression d’initialisation. Il faut savoir que les portées à 
gauche et à droite du signe « = » ne sont pas identiques. La portée à gauche correspond 
à celle de la classe de fermeture, tandis que la portée à droite correspond à celle de 
la définition de l’expression lambda. Dans l’exemple précédent, le nom pw à gauche 
du signe « = » fait référence à une donnée membre de la classe de fermeture, tandis 
que le nom pw à sa droite fait référence à l’objet déclaré avant l’expression lambda, 
c’est-à-dire la variable initialisée par l’appel à std : :make_unique. Par conséquent, 
« pw = std: :move(pw) » signifie « créer une donnée membre pw dans la fermeture et 
l’initialiser avec le résultat de l’invocation de std: :move sur la variable locale pw ». 

Le code présent dans le corps de l’expression lambda se trouve dans la portée de la 
classe de fermeture. Les utilisations de pw font donc référence à la donnée membre de 
la classe de fermeture. 

Dans cet exemple, le commentaire « configurer *pw » indique que, après la création 
du Widget par std: :make_unique et avant la capture du résultat de std: :unique_ptr 
sur ce Widget par l’expression lambda, le Widget est modifié d’une façon ou d’une 
autre. Si cette configuration n’est pas nécessaire, autrement dit si le Widget produit 
par std: :make_unique est dans un état qui autorise sa capture par l’expression lambda, 
la variable locale pw est inutile. En effet, il est alors possible d’initialiser directement 
la donnée membre de la classe de fermeture par std : : ma ke_uni que : 

auto func = [pw = std: :make_unique<Widget>( )] // Initialiser une donnée 

( return pw->isVal idated( ) // membre dans la fermeture 

&& pw->isArchived( ) : 1: // avec le résultat de 

// l’appel à make_unique. 

Cela devrait vous convaincre que la notion de « capture » dans C++ 14 a été 
largement étendue car, en C++11, il est impossible de capturer le résultat d’une 
expression. Vous comprenez également pourquoi cette forme de capture se nomme 
capture généralisée. 

Mais si notre compilateur ne prend pas en charge la capture généralisée de C+ + 14, 
quelles solutions s’offrent à nous ? Comment pouvons-nous arriver à une capture de 
déplacement dans un langage qui n’en dispose pas ? 

Il faut se rappeler qu’une expression lambda n’est qu’une manière de provoquer 
la génération d’une classe et la création d’un objet de cette classe. Tout ce qu’il est 
possible de faire avec une expression lambda, nous pouvons le faire manuellement. 
Voici comment écrire en C+ + 1 1 l’exemple de code C+ + 14 vu précédemment : 

class IsValAndArch { // "est validé et 

public: // archivé", 

using DataType = std: : uni que_pt r<Wi dget> ; 

explicit IsVal AndArch(DataType&& ptr) // Le conseil 25 explique 
: pw(std: :move(ptr) ) H // l’utilisation de std::move. 
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bool operator(K) const 

{ return pw->i sVal idated( ) && pw->i sArchi ved( ) ; ) 

pri vate: 

DataType pw; 

1; 

auto func = IsVal AndArch(std: :make_unique<Widget>( ) ) ; 

Le code est effectivement plus long qu’avec une expression lambda, mais cela ne 
change rien au fait que si nous voulons une classe C++ 11 qui prend en charge le 
déplacement- initialisation de ses données membres, le seul obstacle qui nous sépare 
de notre objectif est le temps passé à sa saisie. 

Si nous préférons conserver les expressions lambda (en raison de leur commodité), 
la capture par déplacement peut être obtenue en C+ + 1 1 de la façon suivante : 

1. déplacer l’objet à capturer dans un objet fonction généré avec std : : bi nd, et 

2. donner à l’expression lambda une référence à l’objet capturé. 

Si vous avez l’habitude de std : : bi nd, le code vous semblera plutôt évident. Dans 
le cas contraire, il vous faudra un peu plus de temps pour le comprendre, mais cela en 
vaut la peine. 

Supposons que nous voulions créer un std : : vector local, y stocker un ensemble 
de valeurs, puis le déplacer dans une fermeture. Voici comment procéder en C+ + 14 : 


std: :vector<double> data; 


// Objet à déplacer dans 
// une fermeture. 

// Rempl i r data . 


auto func = [data = std: :move(data)] 

I /* Ut i 1 isations de data . 


// Capture généralisée de C++14. 
*/ 1 ; 


Les parties importantes du code sont mises en exergue : le type de l’objet à déplacer 
(std : : vector<doubl e>), le nom de cet objet (data) et l’expression d’initialisation pour 
la capture généralisée (std::move(data)). Voici la version C++1 1 équivalente, dans 
laquelle les mêmes parties essentielles sont repérées : 


std: :vector<double> data; // Comme précédemment. 

// Comme précédemment. 

auto func = 

std : : bi nd ( // Simulation de la capture 

[](const std: : vector<double>& data) // généralisée en C++11. 

{ /* Utilisations de data. */ I, 

std: :move(data) 

); 

À l’instar des expressions lambda, std: : bi nd génère des objets fonctions (fonc- 
teurs). Nous appelons les objets fonctions renvoyés par std : : bi nd des objets liaisons. 
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Le premier argument de std: :bind est un objet invocable. Les arguments suivants 
représentent les valeurs qui seront passées à cet objet. 

Un objet liaison contient des copies de tous les arguments transmis à std : : bi nd. 
Pour chaque argument lvalue, l’objet correspondant dans l’objet liaison est construit 
par copie. Pour chaque rvalue, il est construit par déplacement. Dans notre exemple, 

puisque le second argument est une rvalue (le résultat de std::move; voir le 
conseil 23), data est construit par déplacement dans l’objet liaison. Cette 
construction par déplacement constitue le cœur de la simulation de la capture par 
déplacement. En effet, nous contournons l’impossibilité de déplacer une rvalue dans 
une fermeture en C++1 1 par le déplacement d’une rvalue dans un objet liaison. 

Lorsqu’un objet liaison est appelé (autrement dit son opérateur d’appel de fonction 
est invoqué), les arguments qu’il stocke sont passés à l’objet invocable indiqué à 
std : : bi nd. Dans cet exemple, cela signifie que, lorsque f une (l’objet liaison) est appelé, 
la copie de data construite par déplacement dans func est passée en argument à la 
fonction lambda donnée à std : : bi nd. 

Cette expression lambda est identique à celle utilisée en C+ + 14, à l’exception du 
paramètre data que nous avons ajouté pour correspondre à notre objet faussement 
capturé par déplacement. Ce paramètre est une référence lvalue à la copie de data 
dans l’objet liaison. (Il n’est pas une référence rvalue, car, même si l’expression 
d’initialisation de la copie de data, « std: :move(data) », est une rvalue, la copie de 
data est elle-même une lvalue.) Les manipulations de data à l’intérieur de l’expression 
lambda vont donc se faire sur la copie de data construite par déplacement dans l’objet 
liaison. 

Par défaut, la fonction membre operatorf ) de la classe de fermeture générée à 
partir d’une expression lambda est const. Par conséquent, toutes les données membres 
de la fermeture sont const à l’intérieur du corps de l’expression lambda. En revanche, 
la copie de data construite par déplacement dans l’objet liaison n’est pas const. 
Pour empêcher que cette copie de data ne soit modifiée dans l’expression lambda, 
le paramètre de celle-ci est déclaré comme une référence sur const. Si l’expression 
lambda était déclarée mutable, la fonction operatorf ) dans sa classe de fermeture 
ne serait pas déclarée const et nous pourrions omettre const dans la déclaration du 
paramètre de l’expression lambda : 

auto func = 

std : : bi nd ( // Simulation en C++11 de la 

[ ] ( std : :vector<double>& data) mutable // capture généralisée pour 
{ /* Utilisations de data. */ I , // des expressions lambda 

std: rmove(data) // mutables 

): 

Puisqu’un objet liaison stocke des copies de tous les arguments transmis à 
std: : b i n d , l’objet liaison de notre exemple contient une copie de la fermeture 
produite par l’expression lambda donnée dans son premier argument. La durée de vie 
de la fermeture est donc identique à celle de l’objet liaison. Ce point est important 
car il signifie que, tant que la fermeture existe, l’objet liaison qui contient l’objet 
faussement capturé par déplacement existe également. 
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Si c’est la première fois que vous êtes confronté à std : : bi nd, n’hésitez pas à consul- 
ter votre documentation C++ 11 préférée pour que tous les détails des explications 
précédentes se mettent en place. Dans tous les cas, les points fondamentaux suivants 
doivent être clairs : 

• Il n’est pas possible de construire par déplacement un objet dans une fermeture 
C++ 1 1 , mais il est possible de construire par déplacement un objet dans un 
objet liaison C+ + 11. 

• La simulation de la capture par déplacement en C+ + 1 1 consiste à construire par 
déplacement un objet dans un objet liaison, puis à passer par référence l’objet 
construit par déplacement à l’expression lambda. 

• Puisque la durée de vie de l’objet liaison est identique à celle de la fermeture, il 
est possible de considérer que les objets présents dans l’objet liaison se trouvent 
dans la fermeture. 

Prenons un second exemple d’utilisation de std: : b i n d pour simuler la capture 
par déplacement. Voici le code C+ + 14 qui nous a servi précédemment à créer un 
std : : uni que_ptr dans une fermeture : 


auto func = [pw = std: :make_unique<Widget>( )] 
I return pw - > i s V a 1 idated( ) 

&& pw->isArchi ved ( ) : ) ; 


// Comme précédemment, 
// créer pw dans une 
// fermeture. 


Voici son équivalent en C+ + 1 1 : 


auto func = std: : bi nd ( 

[](const std: :unique_ptr<Widget>& pw) 
( return pw->i sVal idated( ) 

&& pw->isArchi ved( ) ; I , 
std: :make_unique<Widget>( ) 

): 


Vous êtes peut-être étonné que nous montrions comment utiliser std : : bi nd pour 
contourner les limites des expressions lambda en C+ + 11 alors que le conseil 34 
préconise l’utilisation des expressions lambda à la place de std : : bi nd. Toutefois, ce 
conseil explique que, en C++1 1, il existe certains cas où std : : bi nd se révèle utile, 
et nous venons d’en décrire un. (Les fonctionnalités de C+ + 14, comme la capture 
généralisée et les paramètres auto font disparaître ces cas.) 


À retenir 

• Utiliser la capture généralisée de C++14 pour déplacer des objets dans des 
fermetures. 

• En C++1 1, simuler la capture généralisée à l'aide de classes écrites à la main ou 
avec std: : bi nd. 
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Les expressions lambda génériques, celles qui utilisent auto dans leurs spécifications des 
paramètres, font partie des fonctionnalités les plus attrayantes de C+ + 14. Leur mise en 
œuvre est simple : la fonction operator( ) dans la classe de fermeture de l’expression 
lambda est un template. Prenons par exemple l’expression lambda suivante : 

auto f = [](auto x){ return func(normal ize(x) ) ; 1; 

Voici l’opérateur d’appel de fonction de la classe de fermeture : 

class SomeCompi 1 erGeneratedCl assName { 

public: 

templ ateCtypename T> // Voir le conseil 3 pour 

auto operator()(T x) const // le type de retour auto. 

( return funcCnormal ize(x) ) ; I 

// Autre fonctionnalité de 

I; // la classe de fermeture. 

Dans cet exemple, l’expression lambda se borne à transmettre son paramètre x à 
normal i ze. Si normal i ze traite différemment les lvalues et les rvalues, cette expression 
lambda est mal écrite, car elle passe toujours une Evalue (le paramètre x) à normal i ze 
même si l’argument quelle a reçu était une rvalue. 

Pour que l’expression lambda soit correcte, elle doit transmettre parfaitement x à 
normal i ze. Pour cela, deux modifications du code sont nécessaires. Premièrement, x 
doit devenir une référence universelle (voir le conseil 24) et, deuxièmement, elle doit 
être passée à normal i ze via std: :forward (voir le conseil 25). Conceptuellement, ces 
changements sont triviaux : 

I auto f = [](auto&& x) 

( return func(normal ize(std: :forward<???>(x) ) ) ; I; 

Toutefois, pour passer du concept à la réalité, nous devons déterminer le type 
à indiquer à std : : forward, c’est-à-dire trouver ce que nous devons mettre à la place 
de ???. 

Habituellement, nous utilisons la transmission parfaite dans le contexte d’une 
fonction template qui prend un paramètre de type T et nous écrivons donc 
std: :forward<T>. Mais, dans l’expression lambda générique, aucun paramètre de type 
T n’est disponible. Il existe bien un T dans la fonction template operatorO à 
l’intérieur de la classe de fermeture générée par cette expression lambda, mais il est 
impossible d’y faire référence à partir de l’expression. 

Le conseil 28 explique que si un argument lvalue est passé à un paramètre qui est 
une référence universelle, le type de ce paramètre devient une référence lvalue. Et si 
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une rvalue est passée, il devient une référence rvalue. Cela signifie que, dans notre 
expression lambda, nous pouvons examiner le type du paramètre x pour déterminer 
si l’argument pas sé était une lvalue ou une rvalue. decl type est là pour nous y aider 
(voir le conseil 3). Si une lvalue (rvalue) aété passée, decltype(x) génère un type qui 
correspond à une référence lvalue (rvalue). 

Le conseil 28 explique également que, lors de l’appel à std: :forward, les conven- 
tions veulent que l’argument de type soit une référence lvalue pour indiquer une lvalue 
et une non-référence pour indiquer une rvalue. Dans notre expression lambda, si x est 
lié à une lvalue, decltype(x) va produire une référence lvalue. Ce fonctionnement 
reste conforme aux conventions. En revanche, si x est lié à une rvalue, decl type(x) 
va donner une référence rvalue à la place de la non-référence d’usage. 

Mais examinons l’exemple d’implémentation C+ + 14 de std::forward tiré du 
conseil 28 : 


templ ate<typename T> // Dans l’espace de 

T&& forward(remove_reference_t<T>& param) // noms std. 

{ 

return static_cast<T&&Xparam) ; 

I 


Si du code client souhaite transmettre parfaitement une rvalue de type Wi dget, il 
instancie normalement std: : forward avec le type Wi dget (c’est-à-dire un type qui 
n’est pas une référence) et le template std : : f orwa rd devient la fonction suivante : 


Widget&& forward(Widget& param) 

I 

return stati c_cast<Widget&&>(param) ; 


// Instanciation de 
// std::forward lorsque 
// T est Hidget. 


Mais voyons ce qui se passe si le code client souhaite transmettre parfaitement la 
même rvalue de type Wi dget et si, au lieu de suivre la convention qui veut que T ne soit 
pas un type référence, il a spécifié une référence rvalue. Autrement dit, examinons le 
fonctionnement lorsque T est Wi dget&&. Après l’instanciation initiale de std : : forward 
et l’application de std: : remove_reference_t, mais avant la réduction de référence (à 
nouveau, voir le conseil 28), std: : forward devient : 


Wi dget&& && forward(Widget& param) 

I 

return static_cast<Widget&& &&Xparam); 


// Instanciation de 
// std::forward lorsque 
// T est Widget&& 

Il (avant la réduction 
Il de référence). 


En appliquant la règle de réduction de référence, qui stipule qu’une référence 
rvalue à une référence rvalue devient une seule référence rvalue, nous obtenons 
l’instanciation suivante : 
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Widget&& forward(Widget& parant) 

I 

return static_cast<Widget&&Xparam) ; 


Il Instanciation de 
Il std : : forward 1 orsque 
Il T est Uidget&& 

Il (après la réduction 
Il de référence) . ) 


Si nous comparons cette instanciation à celle qui résulte de l’appel de std : : f orwa rd 
lorsque T est Widget, nous constatons qu’elles sont identiques. Autrement dit, ins- 
tancier std: : forward avec une référence rvalue donne le même résultat que son 
instanciation avec une non-référence. 

Voilà une très bonne nouvelle, car decltype(x) conduit à un type référence 
rvalue lorsqu’une rvalue est passée au paramètre x de notre expression lambda. Nous 
avons établi précédemment que si une lvalue est passée à notre expression lambda, 
decltype(x) produit le type d’usage à passer à std: :forward, et nous réalisons à 
présent que, pour les rvalues, decltype(x) donne un type non conventionnel pour 
std : : forward mais que nous obtenons le même résultat qu’avec le type conventionnel. 
Par conséquent, que ce soit pour les lvalues ou pour les rvalues, passer decl type(x) 
à std: : forward produit l’effet escompté. Notre expression lambda à transmission 
parfaite peut donc s’écrire de la manière suivante : 


auto f = 

[](auto&& param) 

I 

return 

f une (normal ize($td: :forward<decl type( param) X param ) ) ) ; 

1: 


À partir de là, il est très facile d’obtenir une expression lambda à transmission 
parfaite qui accepte non pas un mais un nombre quelconque de paramètres, car C+ + 14 
reconnaît les expressions lambda variadiques : 


-o 

n 


auto f = 

[](auto&&... params) 

I 

return 

f une (normal ize(std: : f orwa rd<decltype(params)X params) ...)); 


À retenir 

• Utiliser decltype sur les paramètres auto&& pour les passera std: : forward. 


© 
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CONSEIL N° 34. PREFERER LES EXPRESSIONS LAMBDA 

À STD: : BI ND 

std : : bi nd est le successeur C++1 1 des fonctions std : : bi ndlst et std : : bi nd2nd de 
C++98, mais, officieusement, cette fonction fait partie de la bibliothèque standard 
depuis 2005. C’était au moment où le comité de normalisation avait adopté un 
document nommé TRI, qui incluait la spécification de bi nd- (Dans TRI, bind se 
trouvait dans un espace de noms différent et était donc std : : tri : : bi nd, à la place 
de std : : bi nd, avec quelques différences dans les détails de l’interface.) Cette petite 
histoire signifie que certains programmeurs ont une dizaine d’années d’expérience 
avec std : : bi nd et qu’ils ne sont peut-être pas enclins à abandonner un outil qui les 
a bien servis. Cela se comprend parfaitement, mais, dans ce cas, le changement est 
bénéfique car, en C+ + 11, les expressions lambda sont quasiment toujours préférables 
à std : : bi nd. En C++14, l’attirance pour les expressions lambda n’est pas simplement 
plus forte, elle est juste irrésistible. 

Ce conseil suppose que vous maîtrisez std : : bi nd. Dans le cas contraire, commencez 
par en apprendre au moins les bases. Cela vous sera de toute manière profitable, car 
vous aurez certainement l’occasion de rencontrer std: : b i nd dans une base de code 
que vous devrez examiner ou maintenir. 

Comme dans le conseil 32, nous allons appeler objets liaisons les objets fonctions 
retournés par std : : bi nd. 

Voici la principale raison de préférer les expressions lambda à std: : b i n d : elles 
sont plus faciles à lire. Par exemple, supposons que nous ayons une fonction de 
configuration d’une alarme sonore : 


// typedef pour un moment précis (voir le conseil 9 pour la syntaxe), 
using Time = std: rchrono: :steady_clock: : t i me_poi nt ; 


// Voir le conseil 10 pour les "classes enum". 

enum class Sound { Beep, Siren, Whistle I; 

// typedef pour une durée. 

using Duration = std: :chrono: :steady_clock: :duration; 

// À l’instant t, produire un son s pendant une durée d. 

void setAl arm(Time t, Sound s. Duration d): 

Supposons également que, à un certain endroit du programme, nous ayons 
déterminé qu’une alarme doit être déclenchée une heure après qu’elle a été fixée, 
cela pour une durée de 30 secondes. En revanche, le son de l’alarme n’est pas indiqué. 
Nous pouvons écrire une expression lambda qui modifie l’interface de setAl arm afin 
que seul le son puisse être précisé : 

// setSoundL CL" pour "expression lambda") est un objet fonction qui 
// permet de préciser un son pour une alarme de 30 secondes 
// déclenchée une heure après qu’elle a été fixée. 
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auto setSoundL = 

[]( Sound s) 

I 

Il Rendre les éléments de std::chrono disponibles. 

Il sans qualification, 
using namespace std::chrono; 

setAl arm(steady_clock: :now( ) + hours(l), Il Alarme à déclencher 
s. Il dans une heure 

seconds(30) ) ; Il pendant 30 secondes. 


L’appel à setAl arm dans l’expression lambda est mis en exergue. Il s’agit d’un appel 
de fonction d’apparence normale et même le lecteur peu habitué aux expressions 
lambda voit que le paramètre s passé à l’expression lambda est transmis en argument 

à setAl arm. 

En C+ + 14, nous pouvons alléger ce code en profitant des suffixes standard pour les 
secondes (s), millisecondes (ms), heures (h), etc., qui se fondent sur la prise en charge 
par C+ + 11 des littéraux définis par l’utilisateur. Ces suffixes étant disponibles dans 
l’espace de noms std : : 1 i ferai s, nous révisons le code précédent: 


auto setSoundL = 
□ (Sound s) 


using namespace std::chrono; 



using namespace std: : 1 i teral s ; 

II 

Pour les suffixes de C++14 

setAl arm(steady_clock: :now( ) + lh. 

II 

C++14, mais avec la 

s , 

II 

même signification 

30s); 

II 

que précédemment. 


-o 

O 


© 


Notre première tentative d’écriture de l’appel à std : : bi nd correspondant est donné 
ci-après. Elle comporte une erreur, que nous corrigerons par la suite, mais le code juste 
est plus compliqué et cette version simplifiée soulève déjà des problèmes importants : 


using namespace std::chrono; 

n 

Comme précédemment. 

using namespace std : : 1 i teral s ; 

using namespace std: :placeholders; 

n 

n 

Nécessaire à l’utilisation 
de "_1". 

auto setSoundB = 

n 

"B" pour "bind” . 

std: : bi nd ( setAl arm. 

steady_cl ock: :now( ) + lh, 

n 

Incorrect ! Voir ci-eprès. 


- 1 ’ 

I 30s); 

Nous aurions voulu mettre en exergue l’appel à setAl arm comme nous l’avons 
fait dans l’expression lambda, mais cet appel n’existe pas. Le lecteur de ce code doit 
simplement savoir qu’appeler setSoundB invoque setAl arm avec l’heure et la durée 
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précisées dans l’appel à std: : bi nd. Pour le non-initié, le paramètre fictif « _1 » est, 
au fond, magique. Quant au lecteur informé, il devra relier mentalement le chiffre 
indiqué par ce paramètre fictif avec l’emplacement correspondant dans la liste des 
paramètres de std: : bi nd afin de comprendre que le premier argument de l’appel à 
setSoundB est passé en second argument de set Al arm. Puisque le type de cet argument 
n’est pas identifié dans l’appel à std : : bi nd, le lecteur devra consulter la déclaration 
de setAl arm pour connaître le type d’argument à passer à setSoundB. 

Cependant, nous l’avons indiqué, le code n’est pas tout à fait juste. Dans l’ex- 
pression lambda, il est clair que « steady_cl ock: :now( ) + lh » est un argument de 
setAlarm. Son évaluation se fera au moment de l’appel à set Al arm. Cela semble 
logique : nous voulons que l’alarme se déclenche une heure après l’invocation de 
setAlarm. Cependant, dans l’appel à std: :bind, « steady_cl ock: :now( ) + lh » est 
passé en argument non pas à setAlarm mais à std: : b i n d - Autrement dit, cette 
expression sera évaluée au moment de l’appel à std : : bi nd et l’heure calculée par cette 
expression sera enregistrée dans l’objet liaison résultant. En conséquence, l’alarme 
sera déclenchée non pas une heure après l’appel à setAl arm mais une heure après l’appel 
à std: :bind ! 

Pour résoudre ce problème, nous devons demander à std::bind de reporter 
l’évaluation de l’expression jusqu’à l’appel de setAlarm. Cela se fait en imbriquant un 
second appel à std : : bi nd dans le premier : 

auto setSoundB = 
std: :bind(setAlarm, 

std: : bi nd( std : :pl us <> ( ) , steady_clock: :now( ) , lh), 

_1. 

30s ) ; 

Si vous avez l’habitude du template std : : pl us de C++98, vous êtes peut-être sur- 
pris de constater que, dans ce code, aucun type n’est spécifié entre les crochets obliques. 
Autrement dit, nous avons écrit « std : : pl uso » à la place de « std : : pl us <type> ». 
En C+ + 14, nous pouvons généralement omettre l’argument de type avec les templates 
d’opérateurs standard ; nous ne l’avons donc pas indiqué dans ce code. Puisqu’il en 
va autrement en C+ + 1 1, l’appel à std : : bi nd équivalent à l’expression lambda est le 
suivant : 


using namespace std::chrono; // Comme précédemment, 

using namespace std: :pl aceholders ; 

auto setSoundB = 
std: : bi nd ( setAl arm, 

std: : bi nd ( s td : :pl us<steady_clock: :time_point>( ) , 
steady_clock: :now( ) , 
hours(l)) , 

_ 1 , 

seconds(30) ) ; 

Si, à ce stade, l’expression lambda ne vous semble pas plus attrayante, peut-être 
devriez-vous faire contrôler votre vue. 
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Un nouveau problème survient si set Al arm est surchargée. Supposons qu’il existe 
une surcharge prenant un quatrième paramètre afin de préciser le volume de l’alarme : 

I enum class Volume I Normal, Loud, LoudPlusPlus I; 

void setAl arm(Time t, Sound s. Duration d, Volume v); 

Avec l’expression lambda, nous obtenons le même fonctionnement que précé- 
demment, car la résolution de la surcharge choisit la version à trois arguments de 

setAl arm : 

I auto setSoundL = // Comme précédemment. 

[] (Sound s) 


using namespace std::chrono; 

setAl arm(steady_clock: :now( ) + lh. 

// 

Parfait, appelle la 

s , 

II 

version à 3 arguments 

30s): 

II 

de setAlarm. 


1; 


En revanche, avec l’appel à std : : bi nd, la compilation échoue : 


auto setSoundB = // Erreur ! Quelle 

std: : bi nd ( setAl arm , // variante de setAlarm ? 

std: : bi nd ( s td : :pl us<>( ) , 

steady_clock: :now( ) , 
lh). 

_ 1 . 

30s); 

En effet, le compilateur n’a aucun moyen de déterminer laquelle des deux fonctions 
setAlarm il doit passer à std : : bi nd. Il ne dispose que d’un nom de fonction, qui, pris 
de façon isolée, est ambigu. 

Pour que l’appel à std : : bi nd puisse être compilé, nous devons convertir setAlarm 
dans le type de pointeur de fonction approprié : 


© 


using SetAl arm3Paramïype - void(*)(Time t, Sound s. Duration d); 

auto setSoundB = //À présent 

std: :bind(static_cast<SetAl arm3ParamType>(setAl arm) , //valide, 

std: : bi nd ( s td : :pl us<>( ) , 

steady_cl ock: :now( ) , 
lh), 

_ 1 , 

30s); 

Voilà qui amène une autre différence entre les expressions lambda et std : : bi nd. 
Dans l’opérateur d’appel de fonction pour setSoundL (c’est-à-dire l’opérateur d’appel 
de fonction de la classe de fermeture de l’expression lambda), l’appel à setAlarm 
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correspond à une invocation de fonction normale et le compilateur peut le convertir 
en code inline : 


I setSoundLCSound: :Siren) ; // Le corps de setAlarm peut être 

// mis "inl ine" ici . 

En revanche, l’appel à std : : bi nd passe un pointeur de fonction sur setAlarm et 
cela signifie que, dans l’opérateur d’appel de fonction pour setSoundB (c’est-à-dire 
l’opérateur d’appel de fonction pour l’objet liaison), l’appel à setAlarm se fait par 
l’intermédiaire d’un pointeur de fonction. Puisque les compilateurs sont moins enclins 
à convertir les appels via des pointeurs de fonctions en code inline, les appels à 
setAlarm au travers de setSoundB seront moins sujets à une conversion inline que 
ceux qui se font par setSound L : 

I setSoundB(Sound::Siren); // Le corps de setAlarm est moins 

// sujet à une mise "inline” ici. 

Les expressions lambda conduisent donc un code potentiellement plus rapide que 
celui obtenu avec std : : bi nd. 

L’exemple de setAlarm implique un seul appel de fonction simple. Si le code 
comprend des traitements plus complexes, la balance penche nettement en faveur des 
expressions lambda. Par exemple, examinons l’expression lambda C+ + 14 suivante qui 
indique si son argument se trouve entre une valeur minimale (1 owVal ) et une valeur 
maximale (hi g h V a 1 ), lowVal ethighVal étant deux variables locales : 


auto betweenL = 

[lowVal , highVal ] 

(const auto& val) // C++14. 

( return lowVal <= val && val <= highVal; I; 

Nous pouvons implémenter le même fonctionnement avec std: : b i n d , mais le 
code est un tantinet plus obscur : 


using namespace std: :pl aceholders ; // Comme précédemment, 

auto betweenB = 

std : : bi nd( std : : 1 ogi cal_and<>( ) , // C++14. 

std: : bi nd ( s td : : less_equal <>( ) , lowVal, _1), 
std: : bi nd ( s td : : less_equal <>( ) , _1, highVal)); 

En C++ 1 1 , nous devons préciser les types à comparer. Voici l’appel à std : : bi nd 
correspondant : 


auto betweenB = // Version C++11. 

std : : bi nd ( s td : : 1 ogi cal_and<bool > ( ) , 

std: : bi nd ( s td : : less_equal <int>( ) , lowVal, _1), 
std : : bi nd ( std : : 1 ess_equal <i nt>( ) , _1, highVal)): 
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Bien entendu, en C+ + 1 1, l’expression lambda ne peut pas prendre un paramètre 
auto et nous devons donc préciser un type : 

auto betweenL = // Version C++11. 

[1 owVal , hi ghVal ] 

(int val ) 

I return lowVal <= val && val <= highVal; 1; 

Dans un cas comme dans l’autre, nous pensons que vous serez d’accord pour dire que 
la version avec l’expression lambda n’est pas simplement plus courte mais également 
plus compréhensible et facile à maintenir. 

Nous avons indiqué précédemment que, pour les novices de std: : b i n d , ses 
paramètres fictifs (par exemple _ 1 , _2, etc.) ressemblaient énormément à de la magie. 
Cependant, le comportement opaque ne se limite pas aux paramètres fictifs. Supposons 
que nous ayons une fonction pour créer des copies compressées de Wi dget : 

enum class CompLevel { Low, Normal, Hi gh 1; Il Niveau de compression. 

Widget compress(const Widget& w, Il Créer une copie 

CompLevel lev); Il compressée de w. 

Nous voulons créer un objet fonction qui permet d’indiquer le taux de compression 
d’un Wi dget w particulier. L’utilisation suivante de std : : bi nd créera un tel objet : 

Widget w; 

using namespace std : : pl acehol ders ; 

auto compressRateB = std: :bind(compress, w, _1); 

Le w que nous passons à std : : bi nd doit être mémorisé afin qu’il puisse être utilisé 
lors de l’appel ultérieur à compress. Il est stocké à l’intérieur de l’objet compressRateB, 
mais de quelle manière (par valeur ou par référence) ? La solution retenue fait une 
différence, car si w est modifié entre l’appel à std: : b i n d et celui à compressRateB, 
son stockage par référence reflétera le changement, contrairement à son stockage par 
valeur. 

La solution est donc de le stocker par valeur 1 , mais la seule manière de le savoir 
est de se rappeler le fonctionnement de std : : bi nd ; rien ne l’indique dans l’appel à 
std : : bi nd. Comparons cela à l’utilisation d’une expression lambda où la capture par 
valeur ou par référence de w est explicite : 


1 . std : : bi nd effectue toujours une copie de ses arguments, mais le code appelant peut obtenir un 
effet équivalent à un stockage par référence en appliquant std : : ref à un argument. Avec le code 
suivant : 

auto compressRateB = std: :bind(compress, std::ref(w), _1); 
compressRateB se comporte comme s’il détenait non pas une copie mais une référence à w. 
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I auto compressRateL = Il w est capturée par 

[w] (CompLevel lev) Il valeur ; lev est 

I return compressé, lev); (; Il passé par valeur. 

Le passage des paramètres à l’expression lambda est également explicite. Dans cet 
exemple, il est clair que le paramètre 1 ev est passé par valeur : 

I compressRateL(CompLevel : : H i g h ) ; // L’argument est 

// passé par valeur. 

Mais, dans l’appel à l’objet produit par s t d : : b i nd , comment l’argument est-il 
passé ? 

I compressRateB(CompLevel : : H i g h ) ; // Comment l’argument 

// est-il passé ? 

Une fois encore, la seule façon de le savoir est de se rappeler du fonctionnement 
de std ; : bi nd. (Tous les arguments passés aux objets liaisons le sont par référence, car 
l’opérateur d’appel de fonction de tels objets se fonde sur la transmission parfaite.) 

En comparaison des expressions lambda, le code qui utilise std: : b i n d est donc 
moins lisible, moins expressif et potentiellement moins performant. En C++ 14, il n’y 
a aucune bonne raison d’employer std : : bi nd. En revanche, en C++1 1, std : ; bi nd 
peut se justifier dans deux situations spécifiques : 

• Capture par déplacement. Les expressions lambda de C+ + 11 ne proposent 
pas la capture par déplacement, mais il est possible de l’obtenir en combinant 
expression lambda et std : : bi nd. Les détails de la mise en œuvre sont donnés 
dans le conseil 32, qui explique également que la prise en charge de la capture 
généralisée en C+ + 14 ôte le besoin de cette implémentation. 

• Objets fonctions polymorphiques. Puisque l’opérateur d’appel de fonction sur 
un objet liaison utilise la transmission parfaite, il peut accepter des arguments de 
n’importe quel type (à condition de respecter les contraintes de la transmission 
parfaite décrites au conseil 30). Cela peut se révéler utile si nous voulons lier un 
objet avec un template d’opérateur d’appel de fonction. Par exemple, prenons 
la classe suivante : 


class PolyWidget { 
publ ic: 

templ ate<typename T> 

void operator( Mconst T& param); 
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Voici comment lier un PolyWidget avec std: : b i n d : 

PolyWidget pw; 

auto boundPW = std: :bind(pw, _1); 

L’appel de boundPW peut ensuite se faire avec différents types d’arguments : 

boundPW ( 1930 ) ; // Passer un int à 

// PolyWidget: :operator( ) . 

boundPWCnul 1 ptr ) ; // Passer nullptr à 

// PolyWidget: :operator( ) . 

boundPW( "Rosebud" ) ; // Passer une chaîne littérale à 

// PolyWidget: :operator( ) 

Il n’existe aucune approche équivalente avec une expression lambda en C+ + 1 1. 
En revanche, en C++ 14, il suffit d’utiliser une expression lambda avec un 
paramètre auto : 

I auto boundPW = [pw](const auto& param) // C++14. 

I pw(param); ); 

Il s’agit évidemment de cas particuliers, qui ont de plus tendance à se raréfier, car 
les compilateurs qui prennent en charge les expressions lambda de C++ 14 sont de 
plus en plus courants. 

Lorsque bi nd a été ajouté officieusement à C++ en 2005, il constituait une nette 
amélioration par rapport à ses prédécesseurs de 1998. L’arrivée des expressions lambda 
dans C++ 1 1 a rendu std : : bi nd quelque peu obsolète. Depuis C++ 14, il n’existe plus 
aucune bonne raison de l’utiliser. 


À retenir 

• Le code qui utilise les expressions lambda est plus lisible, plus expressif et 
potentiellement plus performant que celui qui emploie std: : bi nd. 

• En C++1 1 uniquement, std: : b i n d peut se révéler utile pour implémenter la 
capture par déplacement ou pour lier des objets à des templates d'opérateurs 
d'appel de fonction. 
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L’une des plus grandes avancées de C++ 11 réside dans l’incorporation de la concur- 
rence au niveau du langage et de la bibliothèque. Les programmeurs habitués des autres 
API de gestion des threads (par exemple les pthreads ou les threads de Windows) sont 
parfois surpris de la rigidité des fonctionnalités de concurrence en C++, mais elle 
vient des contraintes imposées aux développeurs de compilateurs. Toutefois, grâce 
aux garanties qui en découlent au niveau du langage, les programmeurs peuvent, 
pour la première fois dans l’histoire de C++, écrire des applications multithreads au 
comportement cohérent sur toutes les plates-formes. Nous disposons ainsi d’une base 
solide pour construire des bibliothèques d’importance. Par ailleurs, les éléments pour la 
concurrence disponibles dans la bibliothèque standard (tâches, futurs, threads, mutex, 
variables de condition, objets atomiques, etc.) ne forment que le début de ce qui va 
devenir un riche jeu d’outils pour le développement de logiciels concurrents en C++. 

Dans les conseils suivants, n’oubliez pas que la bibliothèque standard comprend 
deux templates pour les futurs : std: : future et std: :shared_future. Leurs différences 
ont souvent peu d’importance et nous parlons simplement de futurs , quelle que soit la 
variante. 

CONSEIL N° 35. PRÉFÉRER LA PROGRAMMATION 
MULTITÂCHE PLUTÔT QUE MULTITHREAD 

Si nous souhaitons exécuter une fonction doAsyncWork de façon asynchrone, deux 
possibilités s’offrent à nous. Nous pouvons créer un std::thread et lui confier 
l’exécution de doAsyncWork. Dans ce cas, nous utilisons une approche basée sur les 
threads : 
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I i nt doAsyncWork( ) ; 

std::thread t(doAsyncWork) ; 

Ou bien, nous pouvons passer doAsyncWork à std: : async. Dans ce cas, la stratégie 
est basée sur les tâches : 

auto fut = std: :async(doAsyncWork) ; Il "fut" pour "futur". 

Avec cette solution, l’objet de fonction transmis à std:: async (par exemple 
doAsyncWork) est considérée comme une tâche. 

De façon générale, l’approche multitâche est supérieure à son équivalent mul- 
tithread, et le peu de code que nous venons de donner en illustre déjà certaines 
raisons. Dans notre exemple, doAsyncWork retourne une valeur et nous pouvons 
raisonnablement supposer qu’elle intéresse le code appelant. Dans le cas d’une 
invocation via un thread, il n’existe aucune manière simple d’accéder à cette valeur. 
En revanche, dans la solution basée sur une tâche, il est très facile de l’obtenir car le 
futur renvoyé par std: : async dispose d’une fonction get. Celle-ci se révèle encore 
plus importante si doAsyncWork lève une exception, car get y donne également accès. 
Avec les threads, une exception lancée par doAsyncWork va conduire à la terminaison 
du programme (par un appel à std : : termi nate). 

Mais il existe une différence plus fondamentale entre la programmation multi- 
thread et la programmation multitâche : le niveau d’abstraction apporté par les tâches 
est plus élevé, ce qui nous affranchit des détails de la gestion des threads. Cette 
observation nous amène à récapituler les trois sens donnés à « thread » dans un logiciel 
C++ concurrent : 

• Les threads matériels correspondent aux threads qui effectuent réellement les 
calculs. Dans les architectures des ordinateurs modernes, chaque cœur du 
processeur offre un ou plusieurs threads matériels. 

• Les threads logiciels (également appelés threads système) sont les threads que le 
système d’exploitation 1 gère sur l’ensemble de ses processus et dont il planifie 
l’exécution par des threads matériels. En général, il est possible de créer plus de 
threads logiciels qu’il n’existe de threads matériels, car, lorsqu’un thread logiciel 
est bloqué (par exemple sur une entrée-sortie ou l’attente d’un mutex ou d’une 
variable de condition), les performances peuvent être augmentées en exécutant 
d’autres threads non bloqués. 

• Les std: : thread sont des objets d’un processus C++ qui représentent les threads 
logiciels sous-jacents. Certains objets std : : thread représentent des descripteurs 
(handles) « nuis », autrement dit ne correspondent à aucun thread logiciel, car 
ils ont été construits par défaut (ils n’ont pas de fonction à exécuter), ont été 
déplacés (le std : : thread destinataire représente le thread logiciel sous-jacent), 
ont été bloqués avec joi n (la fonction qu’ils exécutaient s’est terminée) ou ont 


1 . À supposer qu’il y en ait un, car certains systèmes embarqués en sont dépourvus. 
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été détachés avec detach (le lien entre eux et le thread logiciel sous-jacent a 
été coupé). 

Les threads logiciels sont une ressource limitée. Si nous tentons d’en créer plus que 
ne peut en fournir le système, une exception std : : system_error est lancée. C’est le 
cas même si la fonction à exécuter ne peut pas lever d’exception. Prenons l’exemple 
de doAsyncWork déclarée noexcept : 


int doAsyncWork( ) noexcept; // Voir le conseil 14 pour noexcept. 

L’instruction suivante pourrait déclencher une exception : 


I std : : t h read t(doAsyncWork) ; // Lance une exception s’il n’y a 

// plus de threads disponibles. 

Un logiciel bien écrit doit tenir compte de cette possibilité, mais comment ? Une 
solution consiste à exécuter doAsyncWork sur le thread courant, mais elle risque de 
conduire à une mauvaise répartition de la charge et, si le thread courant est un thread 
de l’interface graphique, à des problèmes de réactivité. Une autre solution consiste 
à attendre que des threads logiciels existants arrivent au terme de leur exécution 
et de retenter la création d’un nouveau std: : thread, mais il est possible que des 
threads existants soient en attente d’une action que doAsyncWork est censé réaliser 
(par exemple renvoyer un résultat ou notifier une variable de condition). 

Même si nous ne sommes pas à court de threads, nous pouvons rencontrer des 
problèmes en raison d’une demande excédentaire. Cela se produit lorsque le nombre de 
threads logiciels prêts à s’exécuter (non bloqués) est supérieur au nombre de threads 
matériels. Dans ce cas, le gestionnaire des threads (qui fait en général partie du système 
d’exploitation) accorde des intervalles de temps matériel aux threads logiciels. Lorsque 
l’intervalle de temps d’un thread est terminé et qu’un autre débute, un changement de 
contexte est réalisé. Ces changements de contexte pèsent sur la gestion des threads par 
le système et peuvent se révéler particulièrement coûteux lorsque le thread matériel 
attribué à un thread logiciel se trouve sur un cœur différent de celui utilisé lors de 
l’intervalle de temps précédent accordé au même thread logiciel. Dans ce cas, ( 1 ) les 
caches du processeur pour ce thread logiciel sont en général invalides (ils contiennent 
peu de données et quelques instructions utiles) et (2) l’exécution du « nouveau » 
thread logiciel sur ce cœur pollue les caches du processeur associés aux « anciens » 
threads qui ont été exécutés sur ce cœur et qui risquent fort de l’être à nouveau lors 
de l’intervalle de temps suivant. 

Il est difficile d’éviter la demande excédentaire, car le rapport optimal entre threads 
logiciels et threads matériels dépend de la fréquence à laquelle les threads logiciels 
deviennent exécutables. Cette fréquence évolue de façon dynamique, par exemple 
lorsqu’un programme passe d’une section qui sollicite énormément les entrées-sorties 
à une portion qui effectue de nombreux calculs. Le rapport optimal dépend également 
du coût des changements de contexte et de l’utilisation des caches du processeur par les 
threads logiciels. D’autre part, le nombre de threads matériels et les détails des caches 
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du processeur (par exemple leur taille et leur rapidité) dépendent de l’architecture 
de la machine. Autrement dit, même si nous parvenons à régler notre application 
de façon à éviter les demandes excédentaires sur une plate-forme (tout en exploitant 
au mieux son matériel), rien ne garantit que notre solution sera efficace sur d’autres 
sortes de machines. 

Notre vie serait beaucoup plus simple si nous pouvions confier la résolution de ces 
problèmes à quelqu’un d’autre. C’est exactement le rôle de std : : async : 

auto fut = std: :async(doAsyncWork) ; // La gestion des threads revient 

// au développeur de la 
// bibliothèque standard. 

Cet appel place la responsabilité de la gestion des threads sur le dos de celui 
qui implémente la bibliothèque standard de C++. Par exemple, la probabilité de 
recevoir une exception en raison d’un manque de threads est considérablement réduite, 
car cet appel n’y conduira probablement jamais. Vous vous demandez certainement 
comment cela est possible. En effet, si nous demandons plus de threads logiciels 
que le système ne peut en fournir, quelle différence cela fait-il que ce soit en créant 
des std: : thread ou en appelant std: : async ? Cela compte car, avec un appel à 

std : : async de cette forme (c’est-à-dire avec la stratégie de démarrage par défaut ; voir 
le conseil 36), rien ne garantit qu’un nouveau thread logiciel sera créé. En revanche, il 
permet au gestionnaire de s’organiser pour que la fonction indiquée (dans cet exemple 
doAsyncWork) soit exécutée sur le thread qui demande le résultat de doAsyncWork (c’est- 
à-dire sur le thread qui invoque get ou wait sur fut). N’importe quel planificateur 
digne de ce nom exploite cette liberté lorsque le système est trop sollicité ou qu’il est 
à court de threads. 

Toutefois, nous avons indiqué précédemment qu’une « exécution sur le thread qui 
a besoin du résultat » peut conduire à des problèmes de répartition de charge et l’entrée 
en scène du gestionnaire des tâches et de std : : async ne les fait pas disparaître pour 
autant. En ce qui concerne la répartition de charge, le gestionnaire aura cependant 
une vision plus complète que nous sur ce qui se passe sur la machine, car il ne gère pas 
uniquement les threads de notre code mais également ceux de tous les processus. 

Avec std: : async, les questions de réactivité liées à un thread de l’interface gra- 
phique persistent, car le planificateur ne peut pas savoir quels threads ont des exigences 
de réactivité fortes. Dans ce cas, nous pouvons passer la stratégie de démarrage 
std : : 1 aunch : : async à std : : async. De cette manière, la fonction s’exécutera sur un 
thread réellement différent (voir le conseil 36). 

Les gestionnaires de threads modernes exploitent des pools de threads de niveau 
système pour éviter les demandes excédentaires et améliorent la répartition de charge 
sur les cœurs matériels grâce à des algorithmes de vol de travail. La norme C++ 
n’impose pas l’utilisation des pools de threads ou du vol de travail et, pour être honnête, 
certains aspects techniques de la spécification de la concurrence en C+ + 11 ne 
permettent pas de les employer aussi facilement que nous le souhaiterions. Néanmoins, 
certaines versions de la bibliothèque standard tirent profit de ces technologies et 
nous pouvons penser que les améliorations vont se poursuivre dans ce domaine. 


Conseil n° 35. Préférer la programmation multitâche plutôt que multithread 
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En basant notre programmation concurrente sur les tâches, nous pourrons bénéficier 
automatiquement des avantages de ces technologies lorsqu’elles deviendront plus 
répandues. En revanche, si nous manipulons directement des std::thread, nous 
devons nous occuper des problèmes de manque de threads, de demandes excédentaires 
et de répartition de la charge, sans compter que nos solutions doivent s’accorder à 
celles mises en œuvre dans les programmes qui s’exécutent sur d’autres processus de la 
même machine. 

Au contraire d’une approche multithread, une conception multitâche nous évite la 
gestion manuelle des threads et fournit une voie naturelle pour examiner les résultats 
(valeurs de retour ou exceptions) des fonctions exécutées de façon asynchrone. Il 
existe néanmoins des cas où les threads peuvent se révéler appropriés : 

• Lorsque nous devons accéder à TAPI de l’implémentation sous-jacente des 
threads. L’API de concurrence de C++ est en général implémentée au-dessus 
d’une API de plus bas niveau spécifique à la plate-forme, comme les pthreads 
ou les threads de Windows. C++ n’offre pas toute la richesse de ces API. (Par 
exemple, les notions de priorité et d’affinité des threads n’existent pas en C++.) 
Pour que nous puissions avoir accès à l’API de l’implémentation sous-jacente des 
threads, les objets std : : thread proposent habituellement la fonction membre 
nati ve_handl e. Il n’existe aucun équivalent à cette fonctionnalité avec les 
std: : future (c’est-à-dire les objets retournés par std: :async). 

• Lorsque nous devons et sommes en mesure d’optimiser l’utilisation des 
threads dans notre application. Cela peut être le cas si, par exemple, nous 
développons un logiciel serveur dont le profil d’exécution est connu et qui 
constituera le seul processus important implanté sur une machine dont les 
caractéristiques matérielles sont figées. 

• Lorsque nous devons implémenter la technologie des threads en dehors de 
l’API de concurrence de C++, par exemple pour proposer des pools de threads 
alors que l’implémentation de C++ sur la plate-forme ne les propose pas. 

Cependant, ces cas sont plutôt rares. En général, une conception basée sur les 
tâches plutôt qu’une programmation avec des threads devra être privilégiée. 


À retenir 

• L'API de std::thread n'offre aucun accès direct aux valeurs de retour des 
fonctions qui s'exécutent de façon asynchrone et, si ces fonctions lancent des 
exceptions, le programme est terminé. 

• La programmation basée sur les threads impose une gestion manuelle du 
manque de threads, de la demande excédentaire, de la répartition de charge et 
de l'adaptation aux nouvelles plates-formes. 

• La programmation basée sur les tâches via std::async et la stratégie de 
démarrage par défaut nous affranchit de la quasi-totalité de ces problèmes. 
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CONSEIL N° 36. SPECIFIER STD: : LAUNCH : : ASYNC 

SI L'ASYNCHRONISME EST PRIMORDIAL 


Lorsque nous appelons std: :async pour exécuter une fonction (ou tout autre objet 
invocable), nous avons généralement à l’idée une exécution asynchrone de cette 
fonction. Mais ce n’est pas forcément ce que nous demandons à std: :async. En 
réalité, nous demandons que la fonction soit exécutée conformément à une stratégie de 
démarrage. Il existe deux stratégies standard, chacune représentée par un énumérateur 
dans Penum délimité de std: : 1 aunch. (Pour de plus amples informations sur les 
enum délimités, consulter le conseil 10.) Supposons qu’une fonction f soit passée à 
std : : async en vue de son exécution : 

• Avec la stratégie de démarrage std: :launch: : async, f doit être exécutée de 
façon asynchrone, c’est-à-dire sur un thread différent. 

• Avec la stratégie de démarrage std: : 1 aunch : :deferred, f peut s’exécuter uni- 
quement lorsque get ou wai t est invoquée sur le futur renvoyé par std : : async 1 . 
Autrement dit, l’exécution de f est reportée jusqu’à ce qu’un tel appel soit 
effectué. Lorsque get ou wai t est invoquée, f est exécutée de façon synchrone, 
autrement dit le code appelant est bloqué jusqu’à la terminaison de f . Si ni get 
ni wai t n’est appelée, f n’est jamais exécutée. 

La stratégie de démarrage par défaut de std : : async, celle utilisée si aucune autre 
n’est précisée, ne correspond à aucune des deux précédentes. En réalité, il s’agit de 
l’une ou de l’autre. Les deux appels suivants ont exactement la même signification : 


auto futl = std: :async(f ) ; 


// Exécuter f en utilisant 
// la stratégie de démarrage 
// par défaut. 


auto fut 2 = std: :async(std: :launch: :async | 

std: :launch: :deferred, 

f): 


// Exécuter f de façon 
// asynchrone ou 
// reportée. 


La stratégie par défaut conduit donc à une exécution synchrone ou asynchrone 
de f. Comme le souligne le conseil 35, cette souplesse permet à std: : async et aux 
composants de gestion des threads de la bibliothèque standard d’assumer la création et 
la destruction des threads, d’éviter la demande excédentaire et de gérer la répartition 


1. Il s’agit d’une simplification. L’important n’est pas le futur sur lequel get ou wai t est invoquée, 
mais l’état partagé auquel le futur fait référence. (Le conseil 38 traite des relations entre les futurs et 
les états partagés.) Puisque std : : future prend en charge le déplacement et peut servir à construire 
un std: : shared_future, et puisqu’un std: : shared_future peut être copié, l’objet futur qui fait 
référence à l’état partagé issu de l’appel à std: : async avec f est probablement différent de celui 
renvoyé par std: :async. Cette explication étant quelque peu compliquée, il est fréquent de cacher 
la pleine vérité et de simplement parler de l’invocation de get ou de wai t sur le futur retourné par 
std : : async. 
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de charge. C’est en partie grâce à tout cela que la programmation concurrente avec 
std : : async est si commode. 

L’utilisation de la stratégie de démarrage par défaut de std:: async présente 
quelques conséquences intéressantes. Supposons qu’un thread t exécute l’instruction 
suivante : 


I auto fut = std: :async(f ) ; // Exécuter f avec la stratégie 

// de démarrage par défaut. 

• Il est impossible de savoir si f s’exécutera de façon concurrente à t, car 

l’exécution de f peut être reportée. 

• Il est impossible de savoir si f s’exécutera sur un thread différent de celui 
qui invoque get ou wai t sur fut. Si ce thread est t, nous ne pouvons pas savoir 
si f s’exécute sur un thread différent de t. 

• Il peut être impossible de savoir si f s’exécutera, car il peut être impossible de 
garantir que get ou wai t sera invoquée sur fut quel que soit le chemin emprunté 
par le programme. 

La souplesse de planification de la stratégie de démarrage par défaut s’accorde 
souvent mal avec l’utilisation des variables thread_l ocal, car, si f lit ou modifie une 
telle zone de mémoire locale de thread (TLS, thread-local storage), il n’est pas possible de 
désigner les variables du thread qui seront manipulées : 


auto fut = std : : async ( f ) ; // TLS pour f potentiel 1 ement pour 

Il un thread indépendent, mais 
Il potentiellement pour le thread 
Il qui invoque get ou wait sur fut. 

Cela affecte également les boucles wait avec temporisation, car l’appel de wa i t_f o r 
ou de wait_until sur une tâche (voir le conseil 35) qui est reportée mène à la 
valeur std : : 1 aunch : : deferred. Autrement dit, la boucle suivante qui semble finir par 
s’arrêter, risque en réalité de s’exécuter indéfiniment : 


© 


using namespace std: : 1 itérai s : 


void f() 

( 

std: :this_thread: : si eep_for ( ls ) : 


auto fut = std: :async(f ) ; 


while ( fut .wai t_for( 100ms ) != 

std: :future_status : :ready) 


// Pour les s uffixes de durée 
// de C++14 ; voir le conseil 34. 

// f s’endort pendant 1 seconde, 
// puis se réveille. 


// Exécuter f de façon asynchrone 
II (conceptuellement) . 

Il Boucler jusqu’à ce que 
Il f soit terminée... ce qui 
Il peut ne jamais arriver ! 
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Si f s’exécute de façon concurrente avec le thread qui appelle std : : async (c’est-à- 
dire si la stratégie de démarrage choisie pour f est std: : 1 a un ch : : async), ce code 
ne pose pas de problème (f se termine un jour). En revanche, si f est reportée, 
fut.wait_for retournera toujours std: : f uture_status : :deferred,qui ne sera jamais 
égal à std : : f uture_status : : ready, et la boucle ne s’arrêtera jamais. 

Il est facile de passer à côté de ce genre de bogue pendant le développement 
et les tests unitaires, car il risque de se manifester uniquement en cas de charge 
importante. Cela correspond aux conditions qui mènent la machine vers une demande 
excédentaire ou un épuisement des threads, car la probablité de report d’une tâche 
est plus élevée. En effet, si le matériel n’est pas menacé de demande excédentaire ou 
d’épuisement des threads, il n’y a aucune raison que le gestionnaire d’exécution ne 
planifie pas une exécution concurrente de la tâche. 

La correction du problème est simple : il suffit d’examiner le futur qui correspond 
à l’appel à std: : async pour savoir si la tâche a été reportée et, dans l’affirmative, 
éviter d’entrer dans la boucle temporisée. Malheureusement, il n’existe aucune 
manière directe de demander à un futur si sa tâche a été reportée. À la place, 
nous devons appeler une fonction temporisée, comme wai t_for, sans véritablement 
attendre quelque chose, mais simplement déterminer si la valeur de retour est 
std: :future_status : :deferred. Oublions l’incongruité du code et appelons wai t_for 
avec une temporisation nulle : 


auto fut = std: :async(f ) ; // Comme précédemment. 

if (fut.wait_for(Os) = // Si la tâche est 

std: :future_status: :deferred) // reportée... 

{ 

// ...invoquer wait ou get sur fut 
// pour appeler f de façon synchrone. 

} else { // La tâche n’est pas reportée, 

while ( fut . wai t_for ( 100ms ) != // Pas de boucle infinie 

std: :future_status: :ready) { // (en supposant que f 

//se termine) . 

// La tâche n’est ni reportée ni prête, par 
// conséquent effectuer le travail concurrent 
// en attendant. 

1 

// fut est prêt. 

} 

En résumé, ces différentes considérations impliquent que nous pouvons utiliser 
std : : async avec la stratégie de démarrage par défaut tant que les conditions suivantes 
sont remplies : 

• La tâche ne doit pas s’exécuter de façon concurrente avec le thread qui appelle 
get ou wai t. 
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• Les variables thread_l ocal lues ou modifiées peuvent être celles de n’importe 
quel thread. 

• get ou wai t est assurée d’être invoquée sur le futur renvoyé par std : : async ou 
l’exécution de la tâche n’est pas indispensable. 

• Le code qui utilise wai t_for ou wai t_unti 1 tient compte du fait que la tâche 
puisse être reportée. 

Lorsque l’une de ces conditions ne peut pas être satisfaite, il est sans doute 
préférable de garantir que std : : async planifiera une exécution asynchrone de la tâche. 
Pour cela, il suffit de passer std : : 1 aunch : : async en premier argument lors de l’appel : 


I auto fut = std: :async(std: :launch: :async, f); // Démarrer f de 

// façon asynchrone. 

En réalité, il est assez pratique de disposer d’une fonction qui opère comme std : : async, 
mais qui utilise automatiquement la stratégie de démarrage std : : 1 aunch : : async, d’autant 
qu’elle est facile à écrire. Voici sa version C++ 1 1 : 


templ ate<typename F, typename... Ts> 
i ni ine 

std: :future<typename std: : resul t_of <F( T s . . . )>: :type> 
reallyAsync(F&& f, Ts&&... params) // Retourner le futur 

( // pour un appel asynchrone 

return std: :async(std: :launch: :async, // à f ( pa rams . . . ) . 
std: :forward<FXf ) , 
std: :forward<Ts>( params). . . ); 


Cette fonction reçoit un obje t invocable f et auc un ou plusieurs paramètres params, 
qu’elle transmet parfaitement (voir le conseil 25) à std: : async, en choisissant la 
stratégie de démarrage std: : 1 aunch: : async. À l’instar de std: : async, elle renvoie un 
std: : future qui résulte de l’appel de f avec params. Il est facile de déterminer le type 
de ce résultat, car le trait de type std : : resul t_of nous le fournit. (Voir le conseil 9 
pour des informations générales sur les traits de type.) 

real lyAsync s’utilise exactement comme std: : async : 


auto fut = real lyAsync(f ) ; // Exécuter f de façon asynchrone ; 

// exception lancée si std::async 
// le peut. 

En C++ 14, nous simplifions la déclaration de la fonction en profitant de la 
déduction du type de retour de real lyAsync : 


© 


templ ate<typename F, typename... Ts> 
i ni ine 

auto 

real lyAsync(F&& f, Ts&&... params) 


// C++14. 
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return std: :async(std: :launch: :async, 
std: :forward<FXf ) , 
std: :forward<Ts>(params) . . . ) ; 


Avec cette version, il apparaît clairement que reallyAsync ne fait rien d’autre 
qu’invoquer std: :async avec la stratégie de démarrage std: : 1 a unch : :async. 


À retenir 

• La stratégie de démarrage par défaut de std::async autorise l'exécution 
synchrone ou asynchrone d'une tâche. 

• Cette souplesse mène à une incertitude de fonctionnement lors des accès à des 
thread_local, implique que la tâche puisse ne jamais s'exécuter et affecte la 
logique du programme pour des appels temporisés à wait. 

• Il faut utiliser std: :launch: :async si l'exécution asynchrone d'une tâche est 
primordiale. 


CONSEIL N° 37. RENDRE LES STD: : THREAD 
NON JOIGNABLES PAR TOUS LES CHEMINS 

Chaque objet std::thread peut être dans l’état joignable ou non joignable. Un 
std: :thread joignable correspond à un thread d’exécution asynchrone sous-jacent 
qui est ou peut être en cours d’exécution. Par exemple, un std : : thread qui représente 
un thread sous-jacent bloqué ou en attente de sa reprise est joignable. Les objets 
std::thread qui correspondent à des threads dont l’exécution est arrivée à son terme 
sont également considérés joignables. 

Un std:: thread non joignable est évidemment un std:: thread qui n’est pas 
joignable. Voici des cas d’objets std : : thread non joignables : 

• std: : thread construits par défaut. Ces std: : thread n’ont aucune fonction à 
exécuter et ne correspondent donc à aucun thread d’exécution sous-jacent. 

• std : : thread qui ont été déplacés. Suite à un déplacement, le thread d’exécution 
sous-jacent auquel correspondait un std: : thread (si c’était le cas) est désormais 
associé à un std: : thread différent. 

• std : : thread qui ont été joints. Après un appel à joi n, l’objet std : : thread ne 
correspond plus au thread d’exécution sous-jacent qui est terminé. 

• std: : thread qui ont été détachés. Un appel à detach coupe le lien entre un 
objet std : : thread et le thread d’exécution sous-jacent qu’il représente. 

Le fait qu’un std : : thread soit joignable est important car, si son destructeur est 
invoqué, l’exécution du programme se termine. Par exemple, supposons que nous 
ayons une fonction doWork qui prend en paramètres une fonction de filtrage, fi 1 ter, 
et une valeur maximale, maxVal . doWork vérifie que toutes les conditions préalables à 
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son action sont remplies, puis elle effectue son traitement avec toutes les valeurs entre 
zéro et maxVal qui traversent le filtre. Si le filtrage et la vérification des conditions 
sont deux opérations qui prennent beaucoup de temps, nous pouvons envisager de les 
effectuer de façon concurrente. 

Pour cela, notre préférence irait vers une conception multitâche (voir le 
conseil 35), mais supposons que nous voulions fixer la priorité du thread qui se charge 
du filtrage. Le conseil 35 explique que cette opération doit se faire au travers 
du descripteur natif du thread, mais il n’est accessible qu’au travers de l’API de 
std: : thread. L’API des tâches (c’est-à-dire des futurs) ne permet pas d’y accéder. 
C’est pourquoi notre solution se fonde non pas sur les tâches mais les threads. Voici le 
code correspondant : 


constexpr auto tenMillion = 10000000; 


// Voir le conseil 15 
// pour constexpr. 


bool doWork(std: :function<bool (int)> filter, 
int maxVal = tenMillion) 


I 


Il Indique si le calcul 
Il a été réalisé ; 

Il voir le conseil 5 
Il pour std: :function. 


std: :vector<int> goodVals; 


Il Valeurs conformes 
// au filtre. 


std::thread t C [&f i 1 ter , maxVal, &goodVa 1 s ] Il Remplir goodVals. 

1 

for (auto i = 0; i <= maxVal; ++i ) 

1 if (filter(i)) goodVal s . pus h_ba c k ( i ) ; I 
I): 


auto nh = t . n a t i v e_h a n d 1 e ( ) ; 

II 

Ut i 

1 iser 

le descripteur 


II 

nat 

if de 

t pour fixer 


II 

1 a 

priori 

té de t. 

if ( conditionsAreSatisfied ( ) ) 1 





t. j o i n ( ) ; 

II 

Lai 

sser t 

se terminer. 

performComputationigoodVals); 





return true; 

1 

II 

Le 

cal cul 

a été fait. 

return false; 

II 

Le 

cal cul 

n’a pas été fait 


Avant que nous n’expliquions pourquoi ce code pose problème, remarquons que la 
valeur d’initialisation de tenMi 1 1 i on pourrait être plus lisible si nous profitions de la 
possibilité que nous offre C++ 14 de séparer les milliers par une apostrophe : 

constexpr auto tenMillion = ÎO'OOO'OOO; // C++14. 

Remarquons également que fixer la priorité de t après que son exécution a débuté, 
c’est un peu songer à fermer la cage quand les oiseaux se sont envolés. Une meilleure 
approche serait de démarrer t dans l’état suspendu (nous permettant alors de régler 
sa priorité avant qu’il ne commence ses calculs), mais ne nous laissons pas distraire 
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par un tel code. S’il vous intéresse, vous pouvez consulter le conseil 39 qui explique 
comment créer des thread suspendus. 

Revenons à doWork. Si condi ti onsAreSati sfi ed( ) renvoie true, tout va bien. En 
revanche, si la fonction renvoie fal se ou lève une exception, l’objet std: : thread t 
sera joignable lorsque son destructeur est invoqué à la fin de doWork. Cela déclenchera 
la terminaison de l’exécution du programme. 

Le destructeur de std::thread se comporte ainsi car les deux autres options 
évidentes sont pires encore : 

• join implicite. Dans ce cas, le destructeur d’un std: : thread attendrait que 
le thread d’exécution asynchrone sous-jacent se termine. Cela peut paraître 
acceptable, mais il serait difficile de localiser l’origine des problèmes de per- 
formance qui pourraient en résulter. Par exemple, il ne serait pas évident de 
comprendre que doWork attend que son filtre soit appliqué à toutes les valeurs si 
condi tionsAreSati sfied( ) a déjà renvoyé fal se. 

• detach implicite. Dans ce cas, le destructeur d’un std: : thread couperait le 
lien entre l’objet std: : thread et son thread d’exécution sous-jacent, mais ce 
dernier ne s’arrête pas pour autant. Cela ne semble pas moins raisonnable 
que l’option join, mais les problèmes de débogage induits risquent d’être 
pires. Par exemple, dans doWork, goodVals est une variable locale capturée 
par référence. Elle est également modifiée dans l’expression lambda (via l’appel 
à push_back). Supposons que pendant l’exécution asynchrone de l’expression 
lambda, condi ti onsAreSati sfi ed( ) retourne fal se. Dans ce cas, doWork se 
termine et ses variables locales (y compris goodVal s) sont détruites. Sa trame 
de pile est effacée et l’exécution du thread se poursuit au point d’appel doWork. 
Les instructions qui suivent ce point vont appeler d’autres fonctions et au moins 
l’une d’elles va occuper une partie ou toute la zone de mémoire dans laquelle 
se trouvait la trame de pile de doWork. Appelons cette fonction f. Pendant 
que f s’exécute, l’expression lambda qui avait été initiée par doWork poursuit 
son exécution asynchrone. Elle peut appeler push_back sur la zone de mémoire 
précédemment occupée dans la pile par goodVals, mais qui se trouve à présent 
quelque part dans la trame de f. Cet appel va donc modifier la mémoire qui 
était utilisée par goodVals et, du point de vue de f, le contenu de sa trame de 
pile peut être modifié à n’importe quel moment ! Imaginez tout le plaisir que 
procurera le débogage d’un tel comportement. 

Le comité de normalisation a décidé que les conséquences de la destruction d’un 
thread joignable étaient suffisamment terribles pour qu’elle soit interdite (en spécifiant 
que la destruction d’un thread joignable provoque la terminaison du programme). 

En raison de ce choix, c’est à nous de faire en sorte que tout objet std::thread 
que nous utilisons soit rendu non joignable dans tous les chemins qui se trouvent en 
dehors de la portée de sa définition. Cependant, il peut être très compliqué de traiter 
tous les chemins, car cela inclut le flux jusqu’à la fin de la portée ainsi que les sorties 
directes avec return, continue, break, goto ou une exception. Les chemins peuvent 
être très nombreux. 
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Chaque fois que nous devons effectuer une action sur tout chemin qui sort d’un 
bloc, l’approche classique consiste à placer cette action dans le destructeur d’un objet 
local. De tels objets sont appelés objets RAII, et les classes correspondantes sont 
appelées classes RAII. (RAII est l’acronyme de Resource Acquisition Is Initialization, 
ou F« acquisition d’une ressource est une initialisation », même si la technique se 
fonde non pas sur une initialisation mais une destruction.) La bibliothèque standard 
regorge de classes RAII. Il s’agit notamment des conteneurs STL (le destructeur 
de chaque conteneur détruit le contenu du conteneur et libère sa mémoire), des 
pointeurs intelligents standard (les conseils 18 à 20 expliquent que le destructeur de 
s td : : uni que_ptr invoque son supprimeur sur l’objet pointé et que les destructeurs de 
std : : shared_ptr et de std: :weak_ptr décrémentent les compteurs de références), des 
objets std: rfstream (les destructeurs ferment les fichiers associés), etc. Pourtant, il 
n’existe aucune classe RAII standard pour les objets std : : thread, probablement parce 
que le comité de normalisation, en ayant écarté joi n et detach des options par défaut, 
ne savait tout simplement pas ce qu’une telle classe devait faire. 

Heureusement, l’écriture de cette classe ne pose aucune difficulté. Par exemple, la 
classe suivante permet au code appelant de préciser si joi n ou detach doit être appelée 
lorsqu’un objet ThreadRAI I (un objet RAII pour un std : : thread) est détruit : 


T3 

O 


class ThreadRAI I { 

public: 

enum class DtorAction I join, detach }; // Voir le conseil 10 pour 

// des infos sur enum class. 


ThreadRAI I (std: :thread&& t, DtorAction a) // Dans le destructeur, 

: action(a), t ( std : : move C t ) ) U // effectuer l’action a sur t. 


-ThreadRAI I( ) 

I 

if (t . joignabl e( ) ) I 

if (action == DtorAction: : join) 
t. join(); 

) else { 
t . detach ( ) ; 


// Voir ci-après pour le 
// test de joignabilité. 


std::thread& get() ( return t; 1 // Voir ci-après, 

pri vate: 

DtorAction action; 
std::thread t; 


Nous pensons que ce code est facile à comprendre de lui-même, mais les points 
suivants pourraient aider : 
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• Le constructeur accepte uniquement des std : : thread rvalues, car nous voulons 
déplacer dans l’objet ThreadRAII le std : :thread passé. (Rappelons que les objets 
std: : thread ne sont pas copiables.) 

• L’ordre choisi pour les paramètres du constructeur est intuitif (préciser tout 
d’abord le std : : thread, puis l’action du destructeur, est plus sensé que l’inverse), 
mais la liste d’initialisation des membres correspond à l’ordre de déclaration 
des données membres qui place l’objet std:: thread en dernier. Dans cette 
classe, l’ordre n’a pas d’importance mais, de façon générale, il est possible que 
l’initialisation d’une donnée membre dépende d’une autre et, puisque les objets 
std : : thread peuvent démarrer l’exécution d’une fonction immédiatement après 
leur initialisation, il est préférable que leur déclaration arrive en dernier dans 
une classe. De cette manière, au moment de leur construction, toutes les 
données membres qui les précèdent auront déjà été initialisées et pourront 
donc être manipulées en toute sécurité par le thread asynchrone qui correspond 
à la donnée membre std::thread. 

• ThreadRAII fournit une fonction get qui donne accès à l’objet std::thread 
sous-jacent. Cela équivaut aux fonctions get des pointeurs intelligents stan- 
dard qui donnent accès aux pointeurs bruts sous-jacents. Grâce à cette 
fonction, ThreadRAII n’a pas besoin de reproduire l’intégralité de l’interface 
de std::thread et les objets ThreadRAII peuvent être employés dans des 
contextes qui requièrent des objets std : : thread. 

• Avant que le destructeur de ThreadRAII n’invoque une fonction membre sur 
l’objet std : : thread t, il s’assure que t est joignable. Ce contrôle est obligatoire 
car l’invocation de joi n ou de detach sur un thread non joignable conduit à un 
comportement indéfini. Il est possible qu’un client ait construit un std : : thread, 
l’ait utilisé pour créer un ThreadRAII, ait invoqué get pour obtenir un accès à t, 
et ait effectué un déplacement à partir de t ou ait appelé joi n ou detach sur t. 
Chacune de ces actions rend t non joignable. 

Examinons la portion de code suivante : 


if (t. joignable( ) ) I 

if (action == DtorAction: : join) { 

t.joinO; 

I else { 
t.detach( ) ; 

I 


Si vous pensez qu’il cache un cas de concurrence, car, entre l’exécution de 
t . joi gnabl e( ) et l’invocation de joi n ou de detach, un autre thread pourrait 
rendre t non joignable, votre intuition est louable mais vos craintes sont 
infondées. En effet, un objet std: : thread ne peut passer de l’état joignable 
à l’état non joignable uniquement au travers d’un appel de fonction, comme 
join, detach ou une opération de déplacement. Au moment où le destructeur 
d’un objet ThreadRAI I est invoqué, aucun autre thread ne peut invoquer une 
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fonction membre de cet objet. En cas d’appels simultanés, il existe bien une 
condition de concurrence, mais elle se trouve non pas dans le destructeur 
mais dans le code client qui tente d’invoquer en même temps deux fonctions 
membres (le destructeur et une autre fonction) sur un même objet. De façon 
générale, les appels simultanés à des fonctions mem bres sur un même o bjet sont 
sûrs uniquement si ces fonctions sont toutes const (voir le conseil 16). 

Voici comment nous utilisons ThreadRAI I dans notre exemple doWork : 


bool doWork(std: :function<bool (int)> filter, // Comme précédemment, 
i nt maxVal = tenMil 1 ion) 

( 

std: : vector<int> goodVals; // Comme précédemment. 

ThreadRAII t( // Utiliser un objet RAI I . 

std: :thread( [&fi 1 ter. maxVal , &goodVals] 

I 

for (auto i = 0; i <= maxVal; ++i ) 

I if (filter(i)) goodVals. pus h_ba ck { i ) : 1 

1 ). 

ThreadRAII: :DtorAction: :join // Action RA I I . 


auto nh = t.get( ) .nati ve_handl e( ) ; 


if (conditionsAreSatisfiedl )) { 
t.get( ) . joi n ( ) ; 
performComputationlgoodVal s ); 
return true; 

1 

return f al se ; 


Dans le destructeur de ThreadRAII, nous avons choisi d’effectuer un join sur le 
thread qui s’exécute de façon asynchrone car, comme nous l’avons vu précédemment, 
un detach pourrait conduire à des problèmes de débogage cauchemardesques. Cepen- 
dant, nous avons également indiqué qu’un join pourrait soulever des problèmes de 
performances, qui, pour être francs, seraient également difficiles à déboguer. Entre un 
comportement indéfini (obtenu par detach), la terminaison du programme (obtenue 
par l’utilisation d’un std: : thread) et des soucis de performances, ces derniers nous 
semblent le moins mauvais choix. 

Hélas, le conseil 39 montre que l’utilisation de ThreadRAI I pour effectuer un joi n 
lors de la destruction d’un std : : thread peut non seulement conduire à des problèmes 
de performances, mais également au blocage du programme. La solution « appropriée » 
à ce type de problème serait d’indiquer à l’expression lambda, qui s’exécute de façon 
asynchrone, que nous n’avons plus besoin d’elle et qu’elle doit se terminer au plus tôt. 
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Malheureusement, C++1 1 ne reconnaît pas les threads interruptibles. Il est possible de 
les implémenter manuellement, mais ce travail sort du cadre de cet ouvrage 1 . 

Le conseil 17 explique que, en raison de la déclaration d’un destructeur dans 
Th read RA 1 1 , le compilateur ne générera aucune opération de déplacement. Cependant, 
rien n’empêche d’avoir des objets ThreadRAI I déplaçahles. Si le compilateur générait 
ces fonctions, elles auraient le comportement approprié. Par conséquent, nous pouvons 
demander explicitement leur création : 


class ThreadRAI I { 
publ ic: 

enum class DtorAction I join, detach 1; // Comme précédemment. 

ThreadRAIKstd: :thread&& t, DtorAction a) // Comme précédemment. 

: action(a), t ( s td : : move ( t ) ) I) 

-ThreadRAI I ( ) 

( 

// Comme précédemment. 


ThreadRAI I( ThreadRAI I&&) = default; 
ThreadRAI I& opéra tor=( Th readRAI I&&) 

std::thread& get() { return t; I 

p r i v a t e : 

DtorAction action; 
std: :thread t; 


// Support du 

= default; // déplacement. 

// Comme précédemment. 
// Comme précédemment. 


À retenir 

• Rendre les std: :thread non joignables sur tous les chemins. 

• Appeler join lors de la destruction peut conduire à des problèmes de 
performances difficiles à déboguer. 

• Appeler detach lors de la destruction peut conduire à un comportement indéfini 
difficile à déboguer. 

• Déclarer les objets std: :thread en dernier dans la liste des membres. 


1. Il est réalisé de manière très intéressante dans la section 9.2 de l’ouvrage C++ Concurrency in 
Action par Anthony Williams (Manning Publications, 2012). 
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CONSEIL N° 38. ÊTRE CONSCIENT DU COMPORTEMENT 
VARIABLE DU DESTRUCTEUR DU DESCRIPTEUR 
DE THREAD 
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Le conseil 37 explique qu’un std: : thread joignable correspond à un thread d’exécu- 
tion système sous-jacent. Le futur d’une tâche non reportée (voir le conseil 36) possède 
une relation comparable avec un thread système. Nous pouvons donc considérer les 
objets std: : thread et les objets futurs comme des descripteurs ( handles ) de threads 
système. 

De ce point de vue, il est intéressant que les destructeurs des std: : thread et 
des futurs aient des comportements aussi différents. Comme nous l’avons noté au 
conseil 37, la destruction d’un std: : thread joignable met fin au programme, car les 
deux autres possibilités, join implicite et detach implicite, semblaient pires encore. 
Pourtant, le comportement du destructeur d’un futur semble correspondre parfois à 
un join implicite, parfois à un detach implicite, et parfois à aucun des deux. Il ne 
provoque jamais la terminaison du programme. Cette diversité de comportement du 
descripteur d’un thread mérite un examen plus approfondi. 

Observons tout d’abord qu’un futur constitue l’une des extrémités d’un canal de 
communication au travers duquel l’appelé transmet un résultat à l’appelant 1 . L’appelé, 
qui s’exécute habituellement de façon asynchrone, écrit le résultat de son traitement 
sur le canal de communication, en général au travers d’un objet std: : promise, et 
l’appelant lit ce résultat en utilisant un futur. La figure 7.1 illustre ce fonctionnement, 
la flèche en pointillés représentant le flux des informations de l’appelé vers l’appelant. 

futur std:: promise 

(normalement) 

Figure 7.1 — Communication au travers d'un futur. 

Mais, où est enregistré le résultat de l’appelé ? Puisque l’appelé peut se terminer 
avant que l’appelant n’invoque get sur le futur correspondant, le résultat ne peut pas 
être stocké dans le std : : promi se de l’appelé. En effet, cet objet est local à l’appelé et 
il est détruit lorsque celui-ci se termine. 

Le résultat ne peut pas être placé dans le futur de l’appelant, car, notamment, un 
std: : future peut servir à créer un std: : shared_future (la propriété du résultat de 
l’appelé est alors transférée du std: : future au std: : shared_future), qui peut ensuite 
être copié à plusieurs reprises après la destruction du std: : future d’origine. Puisque 
certains types de résultats ne pourront pas être copiés (ceux réservés au déplacement) 
et que le résultat peut avoir une durée de vie au moins aussi longue que le dernier 


Appelé 


Appelant 


1. Le conseil 39 explique que le canal de communication associé à un futur peut avoir d’autres 
usages. Mais, dans ce conseil, nous considérons qu’il sert uniquement de mécanisme de transmission 
d’un résultat depuis l’appelé vers l’appelant. 
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futur qui y fait référence, comment déterminer, parmi tous les futurs qui correspondent 
potentiellement à l’appelé, celui qui contient le résultat ? 

Puisqu’aucun des objets associés à l’appelé et qu’aucun des objets associés à l’appe- 
lant ne peuvent servir à mémoriser le résultat de l’appelé, il est placé dans un endroit 
extérieur à ces objets. Cet emplacement est appelé état partagé. Il est généralement 
représenté par un objet sur le tas, mais ses type, interface et implémentation ne sont pas 
spécifiés par la norme. Les auteurs de la bibliothèque standard peuvent implémenter 
les états partagés comme bon leur semble. 

La figure 7.2 montre comment nous pouvons envisager la relation entre l’appelé, 
l’appelant et l’état partagé, où les flèches en pointillés représentent toujours le flux des 
informations. 



futur 

4. 

Etat partagé 

std: : promise 


Appelant 

Résultat 

Appelé 

■T l 

de l'appelé 

(normalement) 


Figure 7.2 — Mémorisation du résultat dans un état partagé. 

L’existence de l’état partagé est importante, car le comportement du destructeur 
d’un futur, sujet de ce conseil, est déterminé par l’état partagé associé au futur : 

• Le destructeur du dernier futur faisant référence à un état partagé pour une 
tâche non reportée lancée via std : : async reste bloqué jusqu’à la terminaison 
de la tâche. En substance, le destructeur d’un tel futur effectue un joi n implicite 
sur le thread qui exécute la tâche asynchrone. 

• Le destructeur de tous les autres futurs détruit simplement l’objet futur. 
Pour les tâches qui s’exécutent de façon asynchrone, cela équivaut à un detach 
implicite sur le thread sous-jacent. S’il s’agit du dernier futur d’une tâche 
reportée, celle-ci ne s’exécutera donc jamais. 

Ces règles semblent plus complexes qu’elles ne le sont. En réalité, nous avons un 
comportement « normal » simple et une exception isolée. Le comportement normal 
est celui d’un destructeur de futur qui détruit l’objet futur. Il n’effectue aucun joi n 
ni detach, et n’exécute rien. Il détruit simplement les données membres du futur. 
(En vérité, il décrémente également le compteur de références présent dans l’état 
partagé manipulé par les futurs qui y font référence et le std : : promi se de l’appelé. Ce 
compteur de références permet à la bibliothèque de savoir quand l’état partagé peut 
être détruit. Pour de plus amples informations sur le comptage de références, consultez 
le conseil 19.) 

L’exception à ce comportement normal se produit uniquement pour un futur qui 
présente l’ensemble des caractéristiques suivantes : 

• Il fait référence à un état partagé qui a été créé suite à un appel à std : : async. 

• La stratégie de démarrage de la tâche est std: :launch: :async (voir le 
conseil 36), soit parce qu’elle a été choisie par le système d’exécution, soit 
parce qu’elle a été indiquée dans l’appel à std : : async. 
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• Le futur est le dernier qui fait référence à l’état partagé. Pour les 

std: : future, ce sera toujours le cas. Pour les std: : shared_future, si d’autres 
std: :shared_future font référence au même état partagé que le futur en cours de 
destruction, ce dernier respecte le comportement normal ( il détruit simplement ses 
données membres). 

Le comportement spécial du destructeur d’un futur ne s’applique que si toutes ces 
conditions sont satisfaites. Il reste bloqué jusqu’à ce que la tâche qui s’exécute de 
façon asynchrone se termine. D’un point de vue pratique, cela correspond à un joi n 
implicite avec le thread qui exécute la tâche créée par std : : async. 

Très souvent, cette exception au comportement normal du destructeur d’un futur 
est résumée par « les futurs de std: : async bloquent dans leur destructeur ». Si, en 
première approximation, ce raccourci est correct, il faut parfois être plus précis. Vous 
connaissez désormais la vérité, dans toute sa beauté. 

Mais vous vous demandez peut-être pourquoi il existe une règle particulière pour 
les états partagés des tâches non reportées qui sont lancées par std: : async. Votre 
interrogation est légitime. Pour ce que nous en savons, le comité de normalisation 
a voulu éviter les problèmes associés à un detach implicite (voir le conseil 37), mais 
n’a pas souhaité adopter une stratégie aussi radicale que la terminaison obligatoire du 
programme (comme ils l’ont fait pour les std : : thread joignables ; voir également le 
conseil 37). Il a donc opté pour un compromis, un joi n implicite. Ce choix n’est pas 
allé sans controverse et des débats ont eu lieu sur l’abandon de ce comportement en 
C++ 14. Finalement, rien n’a changé et le comportement des destructeurs des futurs 
reste cohérent entre C+ + 1 1 et C+ + 14- 

Puisque l’API des futurs ne permet pas de déterminer si un futur fait référence à un 
état partagé issu d’un appel à std : : async, il n’est pas possible de savoir si le destructeur 
d’un objet futur arbitraire sera bloqué dans l’attente de la terminaison d’une tâche 
asynchrone. Ce constat a des implications intéressantes : 


// Le destructeur de ce conteneur pourrait bloquer, car un ou 

// plusieurs des futurs qu’il contient peut faire référence à un état 

// partagé pour une tâche non reportée 1 a ncée via std: :async. 

std: : vector<std: :future<void>> fûts; // Voir le conseil 39 pour des 

// infos sur std: :future<void>. 


class Widget { 
publ ic: 


// Des objets Widget pourraient 
Il bloquer dans leurs destructeurs. 


pri vate: 

std: :shared_future<double> fut; 
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Bien entendu, si nous avons le moyen de savoir qu’un futur donné ne satisfait pas 
aux conditions nécessaires au comportement spécial du destructeur (par exemple, en 
raison de la logique du programme), nous pouvons être assurés que le destructeur de ce 
futur ne bloquera pas. Par exemple, seuls les états partagés qui proviennent d’appels à 
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std : : async peuvent conduire au comportement spécial, mais il existe d’autres façons 
de créer des états partagés. L’une d’elles passe par std: : packaged_task. Un objet 
std: :packaged_task prépare une fonction (ou tout autre objet invocable) pour une 
exécution asynchrone de sorte que son résultat soit placé dans un état partagé. Un 
futur qui fait référence à cet état partagé peut être obtenu à l’aide de la fonction 
get_future de std : : packaged_task : 


int calcValueO; 


// Fonction à exécuter. 


std: :packaged_task<int( )> 
pt(cal cVal ue) ; 


// Emballer calcValue pour qu’elle 
// s’exécute de façon asynchrone. 


auto fut = pt.get_future( ) ; 


// Obtenir un futur pour pt. 


Nous savons ainsi que le futur fut ne fait pas référence à un état partagé créé par 
un appel àstd::async. Son destructeur se comportera donc normalement. 

Après qu’il a été créé, le std: : packaged_task pt peut s’exécuter sur un thread. 
(Il peut également être exécuté par un appel à std: : async, mais si nous voulions 
exécuter une tâche avec std: : async, il n’y a pas vraiment de raison de créer un 
std : : packaged_task, car std : : async réalise la même chose que std : : packaged_task 
avant de planifier l’exécution de la tâche.) 

Puisque les std : : packaged_task ne sont pas copiables, nous devons convertir pt 
en rvalue ( via std: :move ; voir le conseil 23) lorsqu’il est passé au constructeur de 
std: :thread : 


std::thread t ( std : :move(pt) ) : // Exécuter pt sur t. 

Cet exemple donne une idée du comportement normal du destructeur de futur, 
mais il est plus facile à constater lorsque les instructions sont réunies dans un bloc : 


// Début du bloc. 


std: : packaged_task<i n t ( )> 
pt(calcValue) : 

auto fut = pt.get_future( ) ; 

std::thread t ( std : :move(pt) ) ; 


// Voir ci -après. 

t // Fin du bloc. 

Le code le plus intéressant est représenté par les « ... » qui suivent la création de 
l’objet std: : thread t et précèdent la fin du bloc. C’est ce qui arrive à t dans ce code 
qui est intéressant. Il y a trois possibilités élémentaires : 

• Il n’arrive rien à t. Dans ce cas, t sera joignable à la fin de la portée, ce qui 
provoquera la terminaison du programme (voir le conseil 37). 
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• Un joi n est effectué sur t. Dans ce cas, il est inutile que le destructeur de fut 
bloque, car le joi n est déjà présent dans le code appelant. 

• Un detach est effectué sur t. Dans ce cas, il est inutile que le destructeur de 
fut invoque detach, car cette opération est déjà réalisée par le code appelant. 

Autrement dit, lorsque nous avons un futur qui correspond à un état partagé 
issu d’un std: : packaged_task, il est en général inutile d’adopter une stratégie de 
destruction particulière, car le choix entre terminaison, jonction et détachement 
sera effectué par le code qui manipule le std::thread utilisé pour exécuter le 
std: : packaged_task. 


À retenir 

• Le destructeur d'un futur se contente normalement de détruire les données 
membres du futur. 

• Le dernier futur qui fait référence à un état partagé pour une tâche non reportée 
lancée via std: :async bloque jusqu'à la terminaison de la tâche. 


CONSEIL N° 39. ENVISAGER LES FUTURS VOID POUR 
COMMUNIQUER PONCTUELLEMENT UN ÉVÉNEMENT 

Une tâche devra parfois avertir une autre tâche asynchrone de l’arrivée d’un événe- 
ment particulier, car cette seconde tâche ne peut pas effectuer son travail tant que 
cet événement ne s’est pas produit. Il peut s’agir, par exemple, de l’initialisation d’une 
structure de données, de la fin d’une étape d’un calcul ou de la détection d’une valeur 
importante sur un capteur. Dans ce cas, quelle est la meilleure manière de mettre en 
place cette communication interthreads ? 

Une approche évidente consiste à utiliser une variable de condition ( condvar ). Si 
nous appelons tâche de détection la tâche qui détecte la condition, et tâche de réaction 
celle qui réagit à la condition, la stratégie est simple : la tâche de réaction attend 
sur une variable de condition et la tâche de détection notifie cette condvar lorsque 
l’événement se produit. Prenons les variables suivantes : 


std : : condi ti on_vari abl e cv; // condvar pour un événement. 

std::mutex m; // mutex utilisé avec cv. 

Le code de la tâche de détection ne saurait être plus simple : 
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cv.notify_one( ) ; 


// Détecter l’événement. 

// Avertir la tâche de réaction. 
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Si plusieurs tâches de réaction doivent être notifiées, nous pouvons remplacer 
notify_one par n o t i f y_a 1 1 , mais, pour le moment, supposons qu’il n’existe qu’une 
seule tâche de réaction. 

Le code de la tâche de réaction est un peu plus compliqué car, avant d’appeler wa i t 
sur la condvar, il doit verrouiller un mutex au travers d’un objet std : : uni que_l ock. (Le 
verrouillage d’un mutex avant l’attente sur une variable de condition reste classique 
dans les bibliothèques de gestion des threads. La nécessité de verrouiller le mutex via 
un objet std : : uni que_l ock fait simplement partie de l’API C++ 11.) Voici l’approche 
conceptuelle : 


// Préparer la réaction. 


std: : unique_l ockkstd: :mutex> 1 k(m) ; 

cv.wait(lk) ; 


// Ouvrir une section critique 

// Verrouiller le mutex. 

// Attendre la notification ; 
II ce code n’est pas correct ! 

Il Réagir à l’événement 
Il (m est verrouil lé) . 


Il Fermer la section critique : 
Il déverrouiller m via 
Il le destructeur de lk. 


Il Poursuivre la réaction 
Il (m est à présent libéré). 


Le premier problème de cette approche réside dans ce qu’on appelle une mauvaise 
odeur du code (code smell) : même si ce code est opérationnel, il y a quelque chose 
qui sent mauvais (qui ne semble pas correct). Dans ce cas, l’odeur émane du besoin 
d’utiliser un mutex. Les mutex servent à contrôler les accès à des données partagées, 
mais il est parfaitement possible que les tâches de détection et de réaction n’aient pas 
besoin de cette médiation. Par exemple, la tâche de détection peut être responsable 
de l’initialisation d’une structure de données globale, laissant à la tâche de réaction 
le soin de l’utiliser. Si la tâche de détection n’accède jamais à la structure de données 
après l’avoir initialisée et si la tâche de réaction n’y accède jamais avant que la tâche 
de détection n’indique qu’elle est prête, la logique du programme fait en sorte que 
les deux tâches ne se rencontrent jamais. Le mutex est donc inutile. Le fait que la 
solution fondée sur une condvar exige un mutex laisse derrière lui comme un relent 
de mauvaise conception. 

Même en laissant cela de côté, deux autres problèmes doivent absolument être pris 
en compte : 

• Si la tâche de détection notifie la condvar avant que la tâche de réaction 
n’appelle wait, celle-ci va bloquer. Pour que la notification d’une condvar 
réveille une autre tâche, il faut que celle-ci soit en attente sur la condvar. Si 
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la tâche de détection effectue sa notification avant que la tâche de réaction 
n’appelle wai t, elle va manquer la notification et attendre indéfiniment. 

• L’instruction wait ne prend pas en compte les réveils intempestifs. Avec les 
API de gestion des threads (dans de nombreux langages, pas seulement en C+ + ), 
il est possible que le code qui attend sur une variable de condition soit réveillé 
même en l’absence de notification sur la condvar. Il s’agit de réveils intempestifs. 
Un code propre doit les prendre en compte en vérifiant que la condition 
d’attente a bien été satisfaite et procède à ce contrôle immédiatement après le 
réveil. Avec l’API des condvar de C++ cette vérification est exceptionnellement 
simple, car une expression lambda (ou tout autre objet fonction) peut être 
utilisée pour tester la condition d’attente à passer à wai t. Autrement dit, nous 
pouvons écrire ainsi l’appel à wai t dans la tâche de réaction : 

cv.waitd k, 

[]{ return si l’événement s’est produit; I); 

Pour tirer parti de cette possibilité, la tâche de réaction doit être capable de 
déterminer si la condition d’attente est vraie. Mais, dans le scénario que nous 
examinons, la condition d’attente correspond à l’occurrence d’un événement 
que le thread de détection est chargé de reconnaître. Le thread de réaction n’a 
peut-être pas le moyen de déterminer que l’événement qu’il attend a eu lieu et 
c’est pour cela qu’il attend sur une variable de condition ! 

Dans de nombreuses situations, la mise en place d’une communication entre des 
tâches à l’aide d’une condvar convient parfaitement, mais cela ne semble pas le cas ici. 

Une autre approche se fonde sur un drapeau booléen partagé. Ce drapeau est 
initialement fixé à false et, lorsque la tâche de détection reconnaît l’événement 
attendu, elle lève ce drapeau : 

std: :atomic<bool> flag(false); // Drapeau partagé ; voir le 

// conseil 40 pour std: :atomic. 

// Détecter l’événement. 

flag = true; // Notifier la tâche de réaction. 

De son côté, la tâche de réaction consulte simplement l’état du drapeau. Lorsqu’elle 
voit qu’il est positionné, elle sait que l’événement attendu s’est produit : 

// Se préparer à réagir, 
while ( ! f 1 ag ) ; // Attendre l’événement. 

// Réagir à l’événement. 

Cette approche ne souffre pas des inconvénients de la conception à base de condvar. 
Nul besoin d’un mutex, aucun problème si la tâche de détection positionne le drapeau 
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avant que la tâche de réaction ne le consulte, et rien de comparable à un réveil 
intempestif. Très bien. 

En revanche, le coût associé à la consultation du drapeau dans la page de réaction 
est beaucoup moins bien. Pendant que la tâche attend le positionnement du drapeau, 
elle est essentiellement bloquée, même si elle est en cours d’exécution. Elle occupe 
donc un thread matériel dont une autre tâche pourrait profiter, elle entraîne un 
changement de contexte chaque fois que sa tranche de temps débute ou se termine, 
et elle peut entretenir l’exécution d’un cœur qui pourrait sinon être arrêté afin 
d’économiser l’énergie. Une tâche réellement bloquée ne présenterait aucun de ces 
défauts. C’est là l’avantage de l’approche fondée sur une condvar, car une tâche qui se 
trouve dans un appel à wa i t est réellement bloquée. 

Une alternative très répandue consiste à combiner drapeau et condvar. Un drapeau 
indique si l’événement concerné a eu lieu, mais l’accès à cet indicateur est synchronisé 
par un mutex. Puisque le mutex empêche les accès concurrents au drapeau, il est 
inutile, comme l’explique le conseil 40 , que cet indicateur soit un std : : atomi c ; un 
simple bool suffit. Voici la tâche de détection mise en œuvre dans cette solution : 

std : : condi ti on_vari abl e cv; // Comme précédemment, 

std: :mutex m; 

bool flag(false); // Non un std::atomic. 

// Détecter l’événement. 

{ 

std: :lock_guard<std: :mutex> g ( m ) ; // Verrouiller m via 

Il le constructeur de g. 

flag = true; Il Avertir la tâche de réaction 

Il (partie 1). 

} Il Déverrouil 1er m via 

Il le destructeur de g. 

cv.notify_one( ) ; Il Notifier la tâche de réaction 

Il (partie 2). 

Et voici la tâche de réaction : 


Il Se préparer à réagir. 

I II Comme précédemment, 

std: :unique_lock<std: :mutex> lk(m); Il Comme précédemment. 

cv.waitdk, [] { return flag; }); Il Utiliser une expression 

Il lambda pour éviter les 
Il réveils intempestifs. 

Il Réagi r à 1 'événement 
Il (m est verroui lié). 
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I II Poursuivre la réaction 

Il (m est à présent libéré). 

Cette approche évite les problèmes décrits. Elle reste opérationnelle que la tâche 
de réaction appelle wai t avant ou après la notification de la tâche de détection, n’est 
pas sensible aux éventuels réveils intempestifs et ne nécessite aucune interrogation 
active. Pourtant, une odeur perdure. En effet, la tâche de détection communique d’une 
drôle de manière avec la tâche de réaction. En notifiant la variable de condition, la 
tâche de réaction est avertie de l’arrivée probable de l’événement attendu, mais elle 
doit interroger le drapeau pour en être certaine. En positionnant le drapeau, la tâche 
de réaction sait que l’événement s’est bien produit, mais la tâche de détection doit 
néanmoins notifier la variable de condition pour que la tâche de réaction se réveille 
et consulte le drapeau. La solution fonctionne, mais elle ne semble pas très propre. 

Une alternative consiste à éviter les variables de condition, les mutex et les 
drapeaux en faisant en sorte que la tâche de réaction appelle wai t sur un futur fixé 
par la tâche de détection. Cette idée peut sembler bizarre, car le conseil 38 explique 
qu’un futur représente l’extrémité de réception d’un canal de communication entre 
un appelé et un appelant (généralement asynchrone) et qu’il n’existe aucune relation 
appelé-appelant entre les tâches de détection et de réaction. Cependant, le conseil 38 
note également qu’un canal de communication dont l’extrémité d’émission est un 
std::pr omise et dont l’extrémité de réception est un futur peut servir à autre chose 
qu’une simple communication appelé-appelant. Ces canaux de communication sont 
utilisables lorsque nous avons besoin de transmettre des informations d’un endroit 
du programme à un autre. Nous allons nous en servir dans notre exemple pour 
transmettre une information depuis la tâche de détection vers la tâche de réaction. 
Cette information sera l’arrivée de l’événement. 

La conception est simple. La tâche de détection possède un objet std : : promi se 
(c’est-à-dire l’extrémité d’émission du canal de communication) et la tâche de 
réaction dispose du futur correspondant. Lorsque la tâche de détection constate que 
l’événement attendu s’est produit, elle fixe la valeur du std: : promi se (c’est-à-dire 
écrit sur le canal de communication). Pendant ce temps, la tâche de réaction attend 
par wai t sur son futur. Cet appel à wai t bloque la tâche de réaction jusqu’à ce que la 
valeur du std : : promi se ait été fixée. 

std: : promi se et les futurs (std: : future et std: :shared_future) sont des templates 
qui ont besoin d’un paramètre de type. Il indique le type des données transmises au 
travers du canal de communication. Cependant, dans notre cas, nous n’avons aucune 
donnée à transmettre, car la tâche de réaction s’intéresse uniquement au fait que son 
futur a été fixé. Pour ces templates, nous avons donc besoin d’un type qui indique 
qu’aucune donnée n’est transmise sur le canal de communication, autrement dit voi d. 
La tâche de détection utilise donc un std : : promi se< voi d>, et la tâche de réaction, un 
std : : f uture<voi d> ou un std : : shared_f uture<voi d>. La tâche de détection fixe son 
std : : promi se<voi d> lorsque l’événement se produit, et la tâche de réaction attend en 
appelant wait sur son futur. Même si la tâche de réaction ne reçoit aucune donnée 
de la part de la tâche de détection, le canal de communication lui permet de savoir 
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que la tâche de détection a « envoyé » sa donnée voi d en appelant set_val ue sur son 
std: :promi se. 

Avec la déclaration suivante : 

I std :: promi se<void> p; // Objet promise pour le 

// canal de communication. 

Le code de la tâche de détection est simple : 

// Détecter l’événement. 

p.set_value(); // Avertir la tâche de réaction. 

Tout comme celui de la tâche de réaction : 

//Se préparer à réagir. 

p.get_future( ) .wait( ) ; // Attendre sur le futur 

// qui correspond à p. 

// Réagir à l’événement. 

À l’instar de la solution à base d’un drapeau, cette conception ne nécessite aucun 
mutex, fonctionne même si la tâche de détection fixe son std : : promi se avant que la 
tâche de réaction n’appelle wai t, et n’est pas sujette aux réveils intempestifs. (Seules 
les variables de condition sont concernées par ce problème.) Et, comme dans le cas 
de l’approche fondée sur la condvar, la tâche de réaction est réellement bloquée après 
son appel à wa i t et ne consomme donc aucune ressource système pendant l’attente. 
Tout est parfait. 

En réalité, pas vraiment. Certes, l’approche fondée sur un futur permet d’éviter tous 
ces écueils, mais d’autres dangers nous guettent. Par exemple, le conseil 38 explique 
qu’un état partagé se trouve entre un std : : promi se et un futur, et que les états partagés 
sont généralement alloués dynamiquement. Nous devons donc supposer que cette 
conception implique le coût d’une allocation et d’une désallocation sur le tas. 

Mais le plus important est que la valeur d’un std: : promi se ne peut être fixée 
qu’une seule fois. Le canal de communication entre un std: : promi se et un futur 
représente un mécanisme ponctuel : il ne peut être employé à plusieurs reprises. Il s’agit 
là d’une différence importante par rapport aux conceptions à base de condvar et de 
drapeau, dans lesquelles les communications multiples sont possibles. (Une condvar 
peut être modifiée à plusieurs reprises, et un drapeau peut toujours être abaissé et levé 
à nouveau.) 

Cette restriction n’est pas aussi contraignante que vous pourriez le penser. Suppo- 
sons que nous voulions créer un thread système dans un état suspendu. Autrement 
dit, nous voulons que tout le surcoût associé à la création d’un thread soit déporté afin 
d’éviter la latence de sa création lorsque nous sommes prêts à lui faire exécuter un 
traitement. Ou bien, nous voulons le créer dans cet état afin de pouvoir le configurer 
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avant de démarrer son exécution. Pour cela, nous avons besoin de configurer sa priorité 
ou son affinité. L’API de concurrence du C++ ne le permet pas, mais std: :thread 
offre la fonction membre nati ve_handl e, qui donne accès à TAPI de gestion des 
threads de la plate-forme (habituellement les threads POSIX ou les threads Windows). 
Grâce à cette API de plus bas niveau, nous pouvons généralement configurer les 
caractéristiques d’un thread, notamment sa priorité et son affinité. 

En supposant que nous voulions suspendre un thread une seule fois (après sa 
création, mais avant qu’il n’exécute la fonction indiquée), le choix d’une conception 
fondée sur un futur voi d est raisonnable. Voici la technique de base : 


T3 

O 


std: :promise<void> p; 

void reactO; // Fonction pour la tâche de réaction. 

void detectO // Fonction pour la tâche de détection. 

( 

std::thread t([] // Créer un thread. 

i 

p.get_future().wait(); // Suspendre t jusqu’à ce 
reactO; // que le futur soit fixé. 

1 ): 

// Ici, t est suspendu avant 
// 1 'appel à react( ) . 

p.set_val ue( ) ; // Réactiver t, et donc appeler 

// reactO. 

// Autres opérations. 

t.joinO: // Rendre t non joigna ble 

I // (voi r 1 e consei 1 37) . 

Puisqu’il est important que t soit non joignable en dehors de detect, l’utilisation 
d’une classe RAII comme la classe ThreadRAI I du conseil 37 est recommandée. Voici 
le code qui en découle : 


© 


void detectO 


ThreadRAII tr( 

std: :thread([] 


// Utiliser un objet RAII. 


p.get_future( ) .wait( ) ; 
react( ) : 

1 ). 

ThreadRAII: :DtorAction: : joi n II Risqué ! (voir ci-après). 

); 

Il Le thread dans tr 
Il est suspendu i ci . 

p.set_val ueO : Il Réactiver le thread 

Il dans tr. 
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I 1 

Mais il n’est pas aussi fiable qu’il peut paraître. Le problème vient de la première 
section « ... » (celle avec le commentaire « Le thread dans tr est suspendu ici. »). Si 
une exception est levée dans le code correspondant, set_val ue n’est jamais invoquée 
sur p. Autrement dit, l’appel à wai t dans l’expression lambda ne retourne jamais. Par 
conséquent, le thread qui exécute l’expression lambda ne se termine pas. Le problème 
est là, car l’objet RAII tr a été configuré pour effectuer un joi n sur ce thread dans son 
destructeur. En résumé, si une exception est lancée dans la première région de code 
« ... », cette fonction va bloquer car le destructeur de tr ne se terminera jamais. 

Il existe des solutions pour corriger ce problème, mais nous les laissons en exercice 
au lecteur 1 . Nous préférons vous montrer comment le code d’origine (c’est-à-dire sans 
utiliser ThreadRAI I ) peut être modifié pour suspendre puis réactiver non pas une mais 
plusieurs tâches de réaction. Il s’agit d’une généralisation simple, car elle consiste 
à utiliser dans le code react des std: : shared_future à la place d’un std: : future. 
Dès lors que nous savons que la fonction membre share de std: : future transfère la 
propriété de son état partagé à l’objet std : : shared_f uture produit par share, le code 
s’écrit pratiquement de lui-même. La seule subtilité vient du fait que chaque tâche 
de réaction a besoin de sa propre copie du std: : shared_future qui fait référence à 
l’objet partagé. Le std: : shared_future obtenu de share doit donc être capturé par 
valeur par les expressions lambda qui s’exécutent sur les threads de réaction : 


std: :proiïiise<void> p; 

void detect( ) 

I 

auto sf = p.get_future( ).share( ) ; 

std: :vector<std: :thread> vt : 


// Comme précédemment. 

// À présent, plusieurs 
// threads de réaction. 

// Le type de sf est 
// std: :shared_future<void>. 

// Conteneur pour les threads 
// de réaction. 


for (int i = 0; i < threadsToRun : ++i ) 
v t . empl a ce_back ( [ sf ] { sf.waitO ; 

reactO; I): 


// Attendre sur la copie 
// locale de sf ; voir le 
// conseil 42 pour des infos 
// sur emplace_back. 


Il Détecter le blocage si ce code 
Il lance une exception ! 


p.set_val ue ( ) : 


Il Réactiver tous les threads. 


1 . Pour commencer vos recherches, vous pouvez consulter notre article du 24 décembre 2013 publié 
sur le site The View From Aristeia et intitulé « ThreadRAI I + Thread Suspension = Trouble? » 
(http://scottmeyers.blogspot.eom/2013/l 2/threadraii'thread-suspension-trouble. html). 
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for (auto& t : vt) { Il Rendre tous les threads 

t.joinO; Il non joignables ; voir le 

1 II conseil 2 pour des infos 

I II sur "auto&". 

II est remarquable qu’une conception fondée sur les futurs puisse arriver à ce 
fonctionnement et c’est pourquoi vous devez l’envisager pour les communications 
ponctuelles d’un événement. 


A retenir 

• Pour la communication simple d'un événement, les conceptions fondées sur une 
condvar exigent un mutex superflu, posent des contraintes sur la progression 
relative des tâches de détection et de réaction, et demandent aux tâches de 
réaction de vérifier que l'événement a eu lieu. 

• Les conceptions qui reposent sur un drapeau évitent ces problèmes, mais 
mettent en place une interrogation non bloquante. 

• Une condvar et un drapeau peuvent être combinés, mais le mécanisme de 
communication résultant est quelque peu guindé. 

• L'utilisation de std: : promise et de futurs évite ces problèmes, mais cette 
approche utilise le tas pour le stockage des états partagés et se limite à des 
communications ponctuelles. 


CONSEIL N° 40. UTILISER STD: : ATOMIC POUR LA 
CONCURRENCE, VOLATILE POUR LA MÉMOIRE SPÉCIALE 


TD 

o 


© 


Pauvre volatile, si incompris. Il ne devrait même pas être cité dans ce chapitre, 
car il n’a aucun rapport avec la programmation concurrente. Pourtant, dans d’autres 
langages, comme Java et O, il a son utilité dans ce type de programmation, et, même 
en C++, certains compilateurs ont connoté vol ati 1 e d’une sémantique qui le rend 
approprié au développement de logiciels concurrents (mais uniquement lorsqu’ils 
sont compilés avec ces compilateurs). C’est pourquoi il est intéressant de discuter de 
vol ati 1 e dans un chapitre sur la concurrence, ne serait-ce que pour dissiper le flou qui 
l’entoure. 

La fonctionnalité C++ que les programmeurs confondent parfois avec vol a ti 1 e — 
celle qui n’a réellement aucun rapport avec ce chapitre - est le template std : : atomi c. 
Les instanciations de ce template (par exemple std : : atomi c<int>, std: : atomi c<bool >, 
std: : atomi c<Widget*>, etc.) apportent des opérations qui, vues des autres threads, 
sont atomiques. Après qu’un std : : atomi c a été construit, les opérations sur cet objet 
se comportent comme si elles se trouvaient à l’intérieur d’une section critique protégée 
par un mutex, alors qu’elles sont généralement implémentées à l’aide d’instructions 
machines spéciales dont l’efficacité est bien supérieure à l’emploi d’un mutex. 

Prenons le code suivant qui utilise std : : atomi c : 
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std: :atomic<int> ai (0) ; 
ai = 10; 

std: :cout << ai ; 

++ai ; 

—ai ; 


// Initialiser ai à 0. 

// Fixer ai à 10 de façon atomique. 

// Lire la valeur de ai de façon atomique. 
// Incrémenter ai à 11 de façon atomique. 
// Décrémenter ai à 10 de façon atomique. 


Pendant l’exécution de ces instructions, les autres threads qui lisent ai ne 
verraient que la valeur 0, 10 ou 11. Aucune autre valeur n’est possible (en supposant 
évidemment que ai ne soit modifié que par ce seul thread). 

Focalisons-nous sur deux aspects de cet exemple. Premièrement, dans l’instruction 
« std: :cout << ai ; », le fait que ai soit un std: :atomic garantit uniquement que la 
lecture de ai est atomique. Rien n’assure que l’intégralité de l’instruction s’exécute 
de façon atomique. Entre le moment où la valeur de ai est lue et celui oùoperator<< 
est invoqué pour l’écrire sur la sortie standard, un autre thread peut avoir modifié ai . 
Le comportement de l’instruction n’en est pas affecté, car operator<< pour les i nt 
utilise un passage par valeur du i nt à afficher (la valeur envoyée sur la sortie sera donc 
celle lue depuis ai ). Cependant, il est important de comprendre que la seule partie 
atomique de cette instruction est la lecture de la valeur de a i . 

Le second aspect intéressant de cet exemple réside dans le comportement des deux 
dernières instructions, l’incrémentation et la décrémentation de ai . Il s’agit de deux 
opérations de type lecture-modification-écriture (RMW, read-modify-wri te ) , mais elles 
s’exécutent de façon atomique. Voilà l’une des caractéristiques les plus appréciables 
des types std: :atomic : dès lors qu’un objet std: :atomic a été construit, toutes les 
fonctions membres invoquées sur cet objet, y compris celles qui contiennent des 
opérations RMW, sont vues par les autres threads comme atomiques. 

À l’opposé, le code analogue qui utilise volatile n’apporte, dans un contexte 
multithread, aucune garantie particulière : 


volatile int v i ( 0 ) ; 
vi = 10; 

std: :cout << vi ; 
++vi ; 

— vi ; 


// Initialiser vi à 0. 
// Fixer vi à 10. 

// Lire la valeur de vi 
// Incrémenter vi à 11. 
// Décrémenter vi à 10. 


Pendant l’exécution de ce code, les autres threads qui liraient la valeur de vi 
peuvent obtenir n’importe quel entier, comme -12, 68, 4090727, ou autre. Un tel code 
présente un comportement indéfini, car les instructions modifient vi et, si d’autres 
threads consultent vi au même moment, nous avons des lectures et des écritures 
simultanées sur une zone de mémoire qui n’est ni std: :atomic, ni protégée par un 
mutex. Nous sommes devant la définition d’une situation de concurrence. 
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Prenons un exemple concret du comportement différent des std : : atomi c et des 
vol ati 1 e dans un programme multithread. Il met en œuvre un compteur de chaque 
type, incrémenté par plusieurs threads. Les compteurs sont initialisés à 0 : 

std: :atomic<int> a c ( 0 ) : // Compteur "atomique". 

volatile int vcCO ) ; // Compteur "volatil". 

Nous incrémentons ensuite chaque compteur une fois dans deux threads qui 
s’exécutent de façon simultanée : 


/* 

- - Thread 1 - - 

*/ 

/* 

- - Thread 2 


++ac; 



++ac; 


++vc; 



++vc; 


-o 

O 


© 


Lorsque les deux threads sont terminés, la valeur de ac (celle du std: : atomi c) 
doit être égale à 2, car chaque incrémentation est réalisée sous forme d’une opération 
indivisible. En revanche, la valeur de v c peut ne pas être égale à 2, car ses incrémenta- 
tions peuvent ne pas se faire de façon atomique. Chaque incrémentation comprend la 
lecture de la valeur de v c, l’incrémentation de la valeur qui a été lue, et l’écriture du 
résultat dans v c. Mais rien ne garantit que ces trois opérations sont réalisées de façon 
atomique sur un objet vol ati 1 e. Il est donc possible que les opérations individuelles 
de deux incrémentations de vc s’entrelacent de la façon suivante : 

1. Le thread 1 lit la valeur de vc, c’est-à-dire 0. 

2. Le thread 2 lit la valeur de vc, c’est-à-dire toujours 0. 

3. Le thread 1 incrémente la valeur 0 qu’il a lue et obtient 1, puis écrit cette valeur 
dans vc. 

4. Le thread 2 incrémente la valeur 0 qu’il a lue et obtient 1, puis écrit cette valeur 
dans vc. 

La valeur finale de vc est donc 1, même si la variable a été incrémentée deux fois. 

Il ne s’agit pas du seul résultat possible. En général, il est impossible de prévoir la 
valeur finale de vc, car cette variable est impliquée dans une situation de concurrence 
et la norme stipule que de telles situations conduisent à un comportement indéfini, 
autrement dit que le compilateur peut générer un code qui effectue, littéralement, 
n’importe quoi. Bien entendu, les compilateurs ne profitent pas de cette liberté de 
façon inconsidérée. Ils mettent en place des optimisations qui sont valides lorsque les 
programmes ne présentent pas des situations de concurrence, mais elles conduisent à 
des comportements inattendus et imprévisibles dans ceux qui en contiennent. 

Les opérations RMW ne sont pas les seuls cas de concurrence où les std : : atomi c 
réussissent et où les volatile échouent. Supposons qu’une tâche calcule une valeur 
nécessaire à une seconde tâche. Lorsque la première a terminé son calcul, elle 
communique son résultat à la seconde. Le conseil 39 explique que la première tâche 
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peut indiquer à la seconde tâche la disponibilité de la valeur souhaitée en utilisant un 
std : : atomi c<bool >. Voici une mise en œuvre possible de la tâche de calcul : 

std: : atomi c<bool> valAvailable(false) ; 

auto imptValue = computelmportantVal ue( ) ; // Calculer la valeur. 

valAvailable = true; // Indiquer à l’autre tâche 

// qu’elle est disponible. 

En tant qu’êtres humains lisant ce code, nous savons qu’il est essentiel que 
l’affectation de imptVal ue se fasse avant l’affectation de val Avai 1 abl e, mais tous les 
compilateurs y voient deux affectations de variables indépendantes. En règle générale, 
les compilateurs sont autorisés à changer l’ordre des affectations qui n’ont pas de 
rapport l’une avec l’autre. Prenons, par exemple, les affectations suivantes (où a, b, x 
et y sont des variables indépendantes) : 

I a = b; 

x = y; 

Le compilateur peut généralement les réordonner ainsi : 

x = y; 

a = b; 

Même si le compilateur ne change pas l’ordre, le matériel sous-jacent peut le 
faire (ou peut le faire croire à d’autres cœurs), car cela permet parfois d’améliorer les 
performances. 

En revanche, l’utilisation de std : : atomi c impose des restrictions sur les possibilités 
de réorganisation du code. L’une d’elles est qu’aucun code qui, dans le code source, 
précède l’écriture d’une variable std : : atomi c ne peut se faire (ou ne peut apparaître 
aux autres cœurs comme se faisant) ensuite 1 . Prenons le code suivant : 

auto imptValue = computelmportantVal ue ( ) ; // Calculer la valeur. 

valAvailable = true; // Indiquer à l’autre tâche 

// qu’elle est disponible. 

1 . Ce n’est vrai que pour les std : : atomi c qui utilisent la cohérence séquentielle. Il s’agit à la fois du seul 
modèle de concurrence et du modèle par défaut pour les objets std : : atomi c qui emploient la syntaxe 
illustrée dans cet ouvrage. C++ 1 1 reconnaît également des modèles de cohérence dont les règles 
de réorganisation du code sont plus souples. Avec ces modèles lâches (dans le sens assouplis), nous 
pouvons créer des logiciels qui s’exécutent plus rapidement sur certaines architectures matérielles, 
mais leur utilisation donne des logiciels beaucoup plus difficiles à mettre au point, à comprendre et à 
maintenir. Il n’est pas rare que, même pour les experts, des erreurs subtiles se glissent dans le code 
fondé sur des opérations atomiques assouplies et vous devez vous limiter autant que possible à la 
cohérence séquentielle. 
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Il faut non seulement que le compilateur conserve l’ordre des affectations de 
imptValue et de valAvailable, mais également que le code qu’il génère oblige le 
matériel sous-jacent à faire de même. Par conséquent, en déclarant valAvailable 
comme un std: :atomic, nous nous assurons que la contrainte d’ordre essentielle — 
tous les threads doivent voir que imptValue ne change pas après que valAvailable a 
été modifiée - est maintenue. 

En déclarant valAvailable volatile, ces restrictions sur l’ordre du code ne 
s’imposent plus : 

volatile bool val Avail able(fal se) ; 
auto imptValue = computelmportantVal ue( ) ; 

valAvailable = true; // D’autres threads peuvent voir cette 

// affectation avant celle de imptValue ! 

Dans ce cas, le compilateur peut inverser l’ordre des affectations de i mptVa 1 ue et 
de valAvailable. Même s’il ne le fait pas, le code machine généré pourrait ne pas 
empêcher le matériel sous-jacent de donner à du code qui s’exécute sur d’autres cœurs 
la possibilité de voir la modification de val Avai labié avant celle de i mptVal ue. 

Ces deux problèmes - aucune garantie d’atomicité d’exécution et contraintes 
insuffisantes sur l’ordre du code - expliquent pourquoi vol a t i 1 e a peu d’utilité dans 
la programmation concurrente, mais cela n’indique rien sur son éventuel intérêt. En 
bref, il permet d’indiquer au compilateur qu’il manipule une zone de mémoire au 
comportement anormal. 

Si nous écrivons une valeur dans une zone de mémoire « normale », cette valeur 
est conservée jusqu’à ce qu’elle soit remplacée. Supposons que nous ayons un int 
normal : 

int x; 

et une séquence d’opérations sur cette variable : 

I auto y = x; // Lire x. 

y = x; // Lire x à nouveau. 

le compilateur peut optimiser le code généré en supprimant l’affectation de y car 
elle est redondante avec son initialisation. 

Dans le cas d’une mémoire normale, si nous écrivons une valeur à un emplacement 
donné, ne la lisons jamais, puis écrivons à nouveau une valeur à cet emplacement 
mémoire, la première écriture peut être supprimée car elle n’est jamais utilisée. 
Supposons les deux instructions adjacentes suivantes : 

I x = 10; 
x = 20; 


// Écrire x. 

// Écrire x à nouveau. 
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Le compilateur peut retirer la première écriture. Supposons à présent que le code 
source comprenne les instructions suivantes : 


auto y = x; 
y = x; 


// Lire x. 

// Li re x à nouveau. 


x = 10; 
x = 20; 


// Écrire x. 

// Écrire x à nouveau. 


Le compilateur peut considérer qu’il a été écrit ainsi : 


auto y = x; 
x = 20; 


// Lire x. 

// Écrire x. 


Au cas où vous demanderiez qui écrirait du code avec de telles lectures redon- 
dantes et écritures superflues, techniquement appelées « chargements redondants » 
( redundant loads) et « stockages morts » (dead stores), sachez que les programmeurs ne 
le feraient pas directement, tout au moins nous l’espérons. Cependant, après que le 
compilateur a étudié le code source et réalisé l’instanciation des templates, l’inlining et 
les différentes sortes d’optimisation par réorganisation, il n’est pas rare que le résultat 
comprenne des chargements redondants et des stockages morts dont le compilateur 
peut se débarrasser. 

Ces optimisations sont valides uniquement lorsque la mémoire se comporte 
normalement. Ce n’est pas le cas de la mémoire « spéciale ». La mémoire spéciale 
la plus répandue est probablement celle employée pour les entrées-sorties mappées en 
mémoire (memory-mapped I/O). Les emplacements dans cette mémoire sont utilisés 
pour communiquer avec les périphériques, par exemple les capteurs ou les affichages 
externes, les imprimantes, les ports réseau, etc., non pour lire ou écrire de la mémoire 
normale (c’est-à-dire de la RAM). Dans ce contexte, reprenons le code qui contient 
des lectures semble-t-il redondantes : 


I auto y = x; // Li re x. 

y = x; // Li re x à nouveau. 

Si x correspond à la valeur mesurée par un capteur de température, la seconde 
lecture de x n’est pas redondante car la température peut avoir changé entre la 
première et la seconde lecture. 

La situation peut être comparable pour des écritures à première vue superflues. Par 
exemple : 

I x = 10; // Écri re x. 

x = 20; // Écrire x à nouveau. 

Si x représente le port de contrôle d’un émetteur radio, ce code pourrait envoyer des 
commandes à la radio, les valeurs 10 et 20 correspondant à des commandes différentes. 
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L’optimisation sur la première affectation changerait l’ordre des commandes envoyées 
à la radio. 

Pour indiquer au compilateur qu’il manipule de la mémoire spéciale, nous pouvons 
employer vol ati 1 e. Ce mot clé signifie « ne pas optimiser les opérations effectuées sur 
cette mémoire ». Par conséquent, si x correspond à de la mémoire spéciale, elle doit 
être déclarée volatile : 

volatile int x; 

Voyons son effet sur notre séquence de code d’origine : 


auto y = x; 
y = x; 


// Lire x. 

// Lire x à nouveau (ne peut pas être optimisé). 


x = 10; 
x = 20; 


Il Écrire x (ne peut pas être optimisé). 
Il Écrire x à nouveau. 


C’est exactement le comportement que nous voulons si x correspond à de la 
mémoire mappée (ou a été mappée sur un emplacement mémoire partagé entre 
plusieurs processus, etc.). 

Petite question : dans la dernière partie du code, quel est le type de y, int ou 

volatile int 1 ? 

Les chargements redondants et les stockages morts apparents doivent donc être 
conservés lorsque la mémoire manipulée est spéciale. Cela explique pourquoi les 
std : : atomi c ne conviennent pas dans ce contexte. Le compilateur a le droit d’éliminer 
de telles opérations redondantes sur les std : : atomi c. Le code est différent de celui qui 
utilise des vol ati 1 e, mais, en mettant de côté cet aspect pour le moment et en nous 
focalisant sur les possibilités du compilateur, nous pouvons dire que, conceptuellement, 
le compilateur peut prendre le code suivant : 


-o 

n 


std: : atomi c < i n t > x; 

auto y = x; Il 

y = x; // 

x = 10; 
x = 20; 

et l’optimiser ainsi : 


Conceptuellement, lire x 
Conceptuellement, lire x 

Il Écrire x. 

Il Écrire x, à nouveau. 


(voir ci-après), 
à nouveau (voir ci-après) 


1. Le type de y est obtenu par déduction auto, selon les règles décrites au conseil 2. Elles stipulent 
que les qualificatifs const et volatil e sont retirés pour les déclarations de types non pointeurs et 
non références (ce qui est le cas de y). Le type de y est donc un simple i nt. Cela signifie que les 
lectures et écritures redondantes pour y peuvent être enlevées. Dans l’exemple, le compilateur doit 
effectuer l’initialisation et l’affectation de y, car x est vol ati 1 e. La seconde lecture de x peut donc 
© produire une valeur différente de la première. 
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I auto y = x; Il Conceptuellement lire x (voir ci -après), 

x = 20; Il Écri re x. 

Avec la mémoire spéciale, ce comportement est clairement inacceptable. 

En réalité, la compilation de ces deux instructions échouera si x est un 

std; :atomic : 

I auto y = x; // Erreur ! 

y = x; // Erreur ! 

En effet, les opérations de copie pour std::atomic sont supprimées (voir le 
conseil 11), cela pour une bonne raison. Examinons ce qui se produirait si l’initiali- 
sation de y à partir de x passait la compilation. Puisque x est un std : : atomi c, le type 
déduit pour y serait également std ; : atomi c (voir le conseil 2). Nous avons indiqué 
précédemment que l’un des avantages des std: : atomi c résidait dans l’atomicité de 
toutes leurs opérations. Mais, pour que la construction par copie de y à partir de x 
soit atomique, le compilateur devrait générer du code qui lit x et écrit y en une seule 
opération atomique. En général, le matériel n’en est pas capable et la construction par 
copie n’est pas prise en charge pour les types std : : atomi c. L’affectation par copie est 
supprimée pour la même raison. Voilà pourquoi la compilation de l’affectation de x à 
y échoue. (Puisque les opérations de déplacement ne sont pas déclarées explicitement 
dans std:: atomi c, std:: atomi c ne propose ni la construction ni l’affectation par 
déplacement, confonnément aux règles de génération des fonctions spéciales par le 
compilateur décrites dans le conseil 17.) 

Il est possible de placer la valeur de x dans y, mais il faut pour cela utiliser les 
fonctions membres load et store de std: : atomi c. La fonction load lit la valeur d’un 
std : : atomi c de façon atomique, tandis que la fonction store l’écrit de façon atomique. 
Voici le code qui permet d’initialiser y à partir de x, puis de stocker la valeur de x dans 

y : 


std: :atomic<int> y(x.loadO); // Lire x. 

y .store(x.load( ) ) ; // Lire x à nouveau. 

La compilation se passe bien mais, en raison de la lecture de x ( via x . 1 oad ( ) ) avec 
un appel de fonction séparé de l’initialisation ou de la modification de y, il est évident 
qu’il ne faut pas espérer que l’une ou l’autre de ces instructions soit exécutée comme 
une seule opération atomique. 

Le compilateur peut « optimiser » ce code en plaçant la valeur de x dans un registre 
au lieu de la lire à deux reprises : 
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TD 
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register = x. 1 oad( ) ; 

std: :atomic<int> y(register); 

y .store( register ) ; 


// Lire x dans register. 

// Initialiser y avec la valeur 
// de register. 

// Placer la valeur de register dans y. 


Vous le constatez, la variable x n’est lue qu’une seule fois, mais ce type d’optimisa- 
tion doit être évité dans le cas de la mémoire spéciale. (L’optimisation est interdite 
avec les variables volatile.) 

À présent, la situation doit être plus claire : 

• std : : atomi c est utile pour la programmation concurrente, mais pas pour l’accès 
à la mémoire spéciale. 

• vol ati 1 e est utile pour l’accès à la mémoire spéciale, mais pas pour la program- 
mation concurrente. 


Puisque std: : atomi c et volatile ont des utilités différentes, nous pouvons les 
employer ensemble : 


I volatile std: :atomic<int> vai; // Les opérations sur vai sont 

// atomiques et ne doivent pas 
// être optimisées. 

Cela servira si va i correspond à un emplacement d’entrée-sortie mappé en mémoire 
auquel plusieurs threads accèdent de façon concurrente. 

Pour finir, notons que certains développeurs préfèrent employer les fonctions 
membres load et store de std: : atomi c même s’ils n’y sont pas obligés, car le code 
source indique alors que les variables concernées ne sont pas « normales ». Il est 
intéressant de souligner ce fait. L’accès à un std: : atomi c est en général plus lent 
qu’un accès à un objet non std : : atomi c, et nous avons déjà vu que l’utilisation des 
std : : atomi c empêche le compilateur d’appliquer certaines formes de réorganisation 
du code. En invoquant 1 oad et store de std : : atomi c, il est plus facile d’identifier les 
endroits où l’évolutivité risque d’être mise à mal. Du point de vue de la conformité, 
ne pas voir d’appel à store pour une variable servant à communiquer une information 
à d’autres threads (par exemple un drapeau qui indique la disponibilité de données) 
pourrait indiquer que la variable n’a pas été déclarée std : : atomi c alors qu’elle aurait 
dû l’être. 

Toutefois, il s’agit essentiellement d’une question de style, en cela très différente 
du choix entre std : : atomi c et vol ati 1 e. 


À retenir 

• std : : atomi c est utilisé pour les données auxquelles plusieurs threads accèdent 
sans passer par des mutex. Il s'agit d'un outil d'écriture de logiciels concurrents. 

• vol ati 1 e est utilisé lorsque les lectures et les écritures d'une mémoire ne doivent 
pas être optimisées. Il s'agit d'un outil de manipulation de la mémoire spéciale. 
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Pour chaque technique ou fonctionnalité générale de C++, il existe des situations 
dans lesquelles son utilisation est sensée et d’autres où ce n’est pas le cas. Il est souvent 
assez facile de décrire quand l’utilisation d’une technique ou d’une fonctionnalité est 
légitime, mais ce chapitre donne deux exceptions. La technique générale concerne le 
passage par valeur, la fonctionnalité générale, le placement. Leur bonne utilisation est 
conditionnée par un nombre de facteurs si important que le meilleur conseil que nous 
puissions vous donner est d 'envisager leur utilisation. Mais elles sont des piliers de la 
programmation moderne efficace en C+ + . Les conseils qui suivent apportent donc 
les informations dont vous aurez besoin pour déterminer si elles conviennent à votre 
logiciel. 
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CONSEIL N° 41. ENVISAGER UN PASSAGE 
PAR VALEUR POUR LES PARAMÈTRES COPIABLES 
DONT LE DÉPLACEMENT EST BON MARCHÉ 
ET QUI SONT TOUJOURS COPIÉS 

Certains paramètres de fonction sont faits pour être copiés 1 . Par exemple, une fonction 
membre addName pourrait copier son paramètre dans un conteneur privé. Pour des 
raisons d’efficacité, elle copierait les arguments lvalue, mais déplacerait les arguments 
rvalue : 

1. Dans ce conseil, « copier » un paramètre signifie généralement l’utiliser en tant que source d’une 
opération de copie ou de déplacement. Rappelons que la terminologie de C++ ne permet pas de 
différencier une copie réalisée par une opération de copie et une copie réalisée par une opération de 
déplacement. 
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class Widget I 
public: 

void addName(const std::string& newName) 
{ names.push_back(newName) : I 


Il Prendre une Ivalue : 
Il la copier. 


void addName(std: :string&& newName) 

I names.push_back(std: :move( newName) ) ; 


private: 

std: :vector<std: : s t r i n g > names; 


Il Prendre une rvalue ; 
Il la déplacer ; voir le 
Il conseil 25 pour des 
Il infos sur std: :move. 


Cela fonctionne, mais nous devons écrire deux fonctions pour effectuer essentielle- 
ment la même chose. C’est un peu pénible : deux fonctions à déclarer, deux fonctions à 
implémenter, deux fonctions à documenter, deux fonctions à maintenir. Une horreur ! 

Par ailleurs, le code objet comprendra deux fonctions, ce qui risque d’être rédhibi- 
toire si l’empreinte mémoire du programme est un critère essentiel. Dans ce cas, les 
deux fonctions deviendront probablement inline, ce qui éliminera les problèmes de 
gonflement liés à leur existence. Mais, si elles sont mises inline partout, avons-nous 
vraiment besoin de deux fonctions dans le code objet ? 

Une solution alternative consiste à convertir addName en un template qui prend 
une référence universelle (voir le conseil 24) : 


class Widget I 
publ ic: 

templ ateCtypename T> 

void addName(T&& newName) 

( 

names. push_back ( std : :forward<T>(newName) ) ; 


// 

Prendre 

des lvalues 

// 

et des 

rvalues : 

// 

copier 

les lvalues. 

// 

déplacer les rvalues 

n 

voir le 

conseil 25 

n 

pour des infos sur 

n 

std: :fo 

rward. 


Le code source à gérer est moindre, mais l’emploi de références universelles amène 
d’autres complications. Puisque addName est un template, son implémentation doit 
généralement aller dans un fichier d’en-tête. Cela peut conduire à plusieurs fonctions 
dans le code objet, car le template est non seulement instancié différemment pour les 
lvalues et les rvalues, mais également pour les std : : s t ri ng et les types qui peuvent être 
convertis en std : : stri ng (voir le conseil 25). Par ailleurs, certains types d’arguments 
ne peuvent pas être passés via des références universelles (voir le conseil 30) et, si 
du code client transmet des types d’a rguments impropre s, les messages d’erreur du 
compilateur peuvent être perturbants (voir le conseil 27). 

11 serait préférable de trouver une solution qui permette d’écrire des fonctions 
comme addName de sorte que les lvalues soient copiées, que les rvalues soient déplacées, 
qu’il n’y ait qu’une fonction à gérer (dans le code source et dans le code objet), et 
que les difficultés liées aux références universelles soient évitées. Bonne nouvelle, elle 


conseil n° 4 1. Envisager un passage par valeur pour les paramètres copiables... 




existe. Il suffit d’oublier l’une des premières règles apprise lors de nos débuts en tant 
que programmeur C++, à savoir éviter de passer par valeur des objets dont le type est 
défini par l’utilisateur. Pour des paramètres comme newName dans des fonctions comme 
addName, le passage par valeur peut être une stratégie parfaitement raisonnable. 

Avant d’expliquer pourquoi le passage par valeur conviendrait si bien à newName et 
à addName, étudions sa mise en œuvre : 

class Widget I 
publ i c : 

void addName(std: :string newName) 

I narres. push_back(std: : move( newName ) ) ; I 


La seule partie un peu compliquée de ce code réside dans l’application de std : :move 
au paramètre newName. En général, std : :move est employé avec des références rvalue, 
mais, dans ce cas, nous savons que (1) newName est un objet totalement indépendant 
de l’argument passé par l’appelant et modifier newName n’affectera pas ce dernier, et 
que (2) il s’agit de la dernière utilisation de newName et donc que son déplacement 
n’aura aucun impact sur le reste de la fonction. 

Puisqu’il n’existe qu’une seule fonction addName, nous évitons la duplication tant 
dans le code source que dans le code objet. Puisque nous n’utilisons pas une référence 
universelle, nous ne subissons pas le gonflement des fichiers d’en-tête, les cas de 
dysfonctionnements étranges, ni les messages d’erreur perturbants. Mais, qu’en est-il 
de l’efficacité de cette conception ? Le passage par valeur n’est-il pas coûteux ? 

En C++98, il était raisonnable de le supposer. Quel que soit l’argument transmis 
par l’appelant, le paramètre newName aurait été construit par copie. En revanche, en 
C++ 1 1, addName sera construit par copie uniquement pour les Ivalues, alors qu’il sera 
construit par déplacement pour les rvalues. Voyons cela : 

Widget w; 


std::string name( "Bart" ) ; 

w.addName(name) ; Il Appeler addName avec une lvalue. 


I w.addNameCname + "Jenne”); Il Appeler addName avec une rvalue 

Il (voir ci-après). 

Dans le premier appel à addName (passage de name), l’initialisation du paramètre 
newName se fait avec une lvalue. newName est donc construit par copie, comme il le serait 
enC++98. Dans le second appel, newName est initialisé avec l’objet std: : string qui 


// Prendre une lvalue ou 
// une rvalue ; la déplacer. 
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résulte d’un appel à operator+ pour un std: : stri ng (c’est-à-dire l’opération d’ajout). 
Cet objet étant une rvalue, newName est construit par déplacement. 

Ainsi, les Ivalues sont copiées et les rvalues sont déplacées, exactement comme 
nous le voulions. Super ! 

C’est effectivement très bien, mais il ne faut pas oublier certaines mises en garde. 
Cela sera plus facile si nous récapitulons les trois versions de addName envisagées : 


cl ass Widget I 
publ ic: 

void addNameCconst std::string& newName) 
( names.push_back(newName) ; } 

void addName(std: :string&& newName) 

( names . push_back( std : :move(newName) ) ; I 


Il Approche 1 : 

Il surcharges pour 
Il les Ivalues et 
Il les rvalues. 


pri vate: 

std: :vector<std: : s t r i n g > names; 


class Widget I 
publ ic: 

templ atektypename T> 

void addName(T&& newName) 

( names.push_back(std: : forward<T>( newName) ) ; 


// Approche 2 : 

// utiliser une 
// référence universelle. 


class Widget I // Approche 3 : 

public: // passage par valeur, 

void addNameistd: :string newName) 

( names .push_back(std: :move(newName) ) : 1 


Les deux premières versions seront dites « approches par référence », car elles se 
fondent toutes deux sur le passage par référence des paramètres. 

Voici les deux scénarios d’appel étudiés : 

Widget w ; 

std::string name( "Bart" ) ; 

w.addName(name) ; // Passer une lvalue. 

w.addName(name + "Jenne"); // Passer une rvalue. 

Examinons à présent le coût, sur le plan des opérations de copie et de déplacement, 
de l’ajout d’un nom à un Widget, dans le contexte des deux scénarios d’appel et 
de chacune des trois implémentations de addName. Nous ignorerons les éventuelles 
optimisations des opérations de copie et de déplacement que les compilateurs peuvent 
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réaliser car elles dépendent du contexte et du compilateur, et, en pratique, ne changent 
pas le fond de l’analyse. 

• Surcharge : que l’argument transmis soit une lvalue ou une rvalue, il est lié à 
une référence nommée newName. Du point de vue des opérations de copie et de 
déplacement, le coût est nul. Dans la surcharge pour une lvalue, newName est 
copié dans Widget: :names. Dans la surcharge pour une rvalue, il est déplacé. 
Résumé des coûts : une copie pour les lvalues, un déplacement pour les rvalues. 

• Utilisation d’une référence universelle : comme pour la surcharge, l’argument 
de l’appelant est lié à la référence newName. Le coût de cette opération est nul. En 
raison de l’application de std: :forward, les arguments lvalue std: :string sont 
copiés dans Widget: :names, tandis que les arguments rvalue std: : string sont 
déplacés. En résumé, les coûts pour les arguments std::string sont identiques 
à ceux de la surcharge : une copie pour les lvalues, un déplacement pour les 
rvalues. 

Le conseil 25 explique que si l’argument passé n’est pas un std: : string, il 
sera transmis à un constructeur de std: : string, ce qui pourra ne provoquer 
aucune opération de copie ou de déplacement d’un std : : stri ng. Les fonctions 
qui prennent en arguments des références universelles peuvent donc être très 
efficaces, mais, puisque cela n’affecte pas notre analyse dans le contexte de ce 
conseil, nous supposerons simplement que les appelants transmettent toujours 
des arguments std : : stri ng. 

• Passage par valeur : que l’argument soit une lvalue ou une rvalue, le paramètre 
newName doit être construit. Dans le cas d’une lvalue, cela coûte une construction 
par copie. Dans le cas d’une rvalue, le coût est celui d’une construction par 
déplacement. Dans le corps de la fonction, newName est systématiquement 
déplacé dans Wi dget : marnes. Résumé des coûts : une copie plus un déplacement 
pour les lvalues, deux déplacements pour les rvalues. En comparaison des 
approches par référence, nous avons donc un déplacement supplémentaire pour 
les lvalues et les rvalues. 

Reprenons l’intitulé de ce conseil : 


Envisager un passage par valeur pour les paramètres copiables dont le déplacement 
est bon marché et qui sont toujours copiés. 


Si nous l’avons écrit de cette manière, c’est pour une bonne raison ; quatre en 
réalité : 

1. Nous devons uniquement envisager le passage par valeur. Oui, il permet de 
n’écrire qu’une seule fonction. Oui, il génère une seule fonction dans le code 
objet. Oui, il évite les problèmes associés aux références universelles. En 
revanche, son coût est plus élevé que celui des autres approches et, comme 
nous le verrons plus loin, certains cas cachent des dépenses que nous n’avons 
pas encore abordées. 
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Étudions une classe qui comprend une donnée membre std: :unique_ptr 
<std : : stri n g > et le mutateur associé. Puisque std : : unique_ptr est un 
type réservé au déplacement, l’approche « par surcharge » pour ce mutateur 
est constituée d’une seule fonction : 

2. Le passage par valeur doit être envisagé uniquement pour les paramètres copiables. 
Les paramètres qui ne satisfont pas à ce critère sont certainement d’un type 
réservé au déplacement car, s’ils ne sont pas copiables et bien que la fonction 
réalise toujours une copie, cette copie doit être créée par le constructeur de 
déplacement 1 . Rappelons que, par rapport à la surcharge, le passage par valeur a 
l’avantage d’exiger l’écriture d’une seule fonction. Mais, pour les types réservés 
au déplacement, il est inutile de fournir une surcharge pour les arguments lvalue. 
En effet, la copie d’une lvalue implique l’appel du constructeur de copie, qui 
est désactivé pour les types réservés au déplacement. Autrement dit, seuls les 
arguments rvalue doivent être pris en charge et, dans ce cas, l’approche « par 
surcharge » n’a besoin que d’une seule surcharge : celle qui prend une référence 
rvalue. 

class Widget I 

publ ic: 

void setPtristd: :unique_ptr<std: : st ri ng>&& ptr) 

( p = std: :move(ptr) : I 

pri vate: 

std: :unique_ptr<std: :string> p; 


Voici comment l’employer dans le code appelant : 

Widget w ; 


w.setPtr(std: :make_unique<std: :string>("Modern C++")) ; 

Le std: : uni que_pt r<std : : string) rvalue retourné par std: :make_unique (voir 
le conseil 21) est passé comme une référence rvalue à set Ptr, où il est déplacé 
dans la donnée membre p. Le coût total correspond à un déplacement. 
Supposons que setPtr prenne son paramètre par valeur : 

class Widget I 
publ ic: 


1. C’est en raison de phrases comme celle-ci qu’il serait bon de disposer d’une terminologie qui 
distingue les copies effectuées par des opérations de copie et celles effectuées par des opérations de 
déplacement. 
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void setPtr(std: :unique_ptr<std: :string> ptr) 
I p = std: : move ( pt r ) ; I 


Le même appel construit par déplacement le paramètre ptr, et ptr est ensuite 
affecté à la donnée membre de p. Le coût total est donc celui de deux 
déplacements, c’est-à-dire deux fois le coût de l’approche « par surcharge ». 

3. Le passage par valeur doit être envisagé uniquement pour les paramètres dont 
le déplacement est bon marché. Lorsque le coût des déplacements est faible, nous 
pouvons accepter un déplacement supplémentaire. Dans le cas contraire, un 
déplacement inutile équivaut à une copie inutile et c’est justement l’importance 
d’éviter les opérations de copie inutiles qui recommande d’éviter le passage par 
valeur en C++98 ! 

4. Le passage par valeur doit être envisagé uniquement pour les paramètres qui 
sont toujours copiés. Pour comprendre l’importance de ce point, supposons que, 
avant de copier son paramètre dans le conteneur names, addName vérifie si le 
nom est trop court ou trop long. Dans l’affirmative, la demande d’ajout du nom 
est ignorée. Voici comment nous pourrions écrire une implémentation avec 
passage par valeur : 

class Widget { 

publ i c : 

void addName (std: : s t r i n g newName) 

I 

if ((newName. lengthO >= minLen) && 

(newName. 1 ength ( ) <= maxLen)) 

I 

names . pus h_ba c k ( std: : move ( newName ) ) ; 


-o 

O 


© 


I private: 

std: :vector<std: :string> names; 

Cette fonction impose des coûts de construction et de destruction de newName, 
même si rien n’est ajouté à names. C’est un prix que les approches par référence 
ne demanderaient pas de payer. 

Même lorsque la fonction réalise une copie inconditionnelle d’un type copiable 
dont le déplacement est bon marché, le passage par valeur peut ne pas convenir. En 
effet, une fonction a deux façons de copier un paramètre : par construction (c’est-à-dire 
construction par copie ou construction par déplacement) et par affectation (c’est-à-dire 
affectation par copie ou affectation par déplacement). addName utilise la construction : 
son paramètre newName est passé à vector: : pu s h_ba c k, et, dans cette fonction, newName 
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sert à créer un nouvel élément à la fin du std: :vector en utilisant la construction 
par copie Dans le cas d’une fonction qui emploie la construction pour copier ses 
paramètres, l’analyse précédente est terminée : l’utilisation du passage par valeur 
implique le coût d’un déplacement supplémentaire pour les arguments lvalue et rvalue. 

Le cas de la copie d’un paramètre par affectation est plus complexe. Supposons, 
par exemple, que nous ayons une classe qui représente des mots de passe. Puisqu’un 
mot de passe peut être modifié, elle offre un mutateur, changeTo. Avec une stratégie 
de passage par valeur, nous pouvons implémenter Password de la manière suivante : 


class Password I 
publ ic: 

explicit Password(std: :string pwd) // Passage par valeur. 
: text(std: :move(pwd) ) (1 II Construire text. 


void changeTo(std: :string newPwd) 
( text = std: :move(newPwd) ; I 


Il Passage par valeur. 
Il Affecter text. 


pri vate: 

std : : st r i ng text; Il Texte du mot de passe. 

I: 


En stockant le mot de passe sous forme d’un texte en clair, nous allons faire hurler 
l’équipe chargée de la sécurité des logiciels, mais ignorons cela et examinons le code 
suivant : 

std: : string 1 ni tPwd( "Supercal if ragi 1 i sticexpi al idocious" ) ; 

Password p(initPwd); 

Aucune surprise ici : p.text est construit à partir du mot de passe indiqué et, 
en utilisant le passage par valeur dans le constructeur, nous avons le coût d’une 
construction par déplacement d’un std : : stri ng, qui ne serait pas nécessaire avec la 
surcharge ou la transmission parfaite. Tout va bien. 

Un utilisateur de ce programme pourrait ne pas être très satisfait du mot de passe, 
car « Supercalifragilisticexpialidocious » se trouve dans de nombreux dictionnaires. Il 
pourrait donc mener des actions qui conduiraient à l’exécution d’un code équivalent 
à celui : 

std::string newPassword = "Beware the Jabberwock”; 

p.changeTo(newPassword) ; 

Nous pouvons toujours discuter de la robustesse de ce nouveau mot de passe par 
rapport à l’ancien, mais c’est le problème de l’utilisateur. Le nôtre est que, en raison 
de la copie par affectation du paramètre newPwd dans changeTo, la stratégie de passage 
par valeur choisie par la fonction risque de faire exploser les coûts. 
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Puisque l’argument passé à changeTo est une lvalue (newPassword), le constructeur 
de copie de s td : : string est invoqué pour construire le paramètre newPwd. Ce 
constructeur alloue de la mémoire pour stocker le nouveau mot de passe. newPwd 
est ensuite affecté par déplacement à text, ce qui provoque la désallocation de la 
mémoire occupée par text. Nous avons donc deux opérations de gestion de la mémoire 
dynamique dans changeTo : l’une pour allouer de la mémoire au nouveau mot de passe, 
l’autre pour libérer la mémoire associée à l’ancien mot de passe. 

Mais, dans ce cas, puisque l’ancien mot de passe (« Supercalifragilisticexpialido- 
cious ») est plus long que le nouveau (« Beware the Jabberwock »), il est inutile 
d’allouer ou de libérer de la mémoire. Avec l’approche par surcharge, il est probable 
qu’aucune de ces actions n’aurait lieu : 


class Password ( 
publ ic: 


void changeïo(const std::string& newPwd) 


// Surcharge pour 
// les lvalues. 


text = newPwd; 


Il Réutilisation possible de la mémoire de text 
Il si text.capacityi ) >= newPwd. size( ) . 


pri vate: 

std::string text; 


Il Comme précédemment. 


-o 

O 


© 


Dans ce scénario, le coût du passage par valeur comprend une allocation et une 
désallocation mémoire supplémentaires. Ces coûts secondaires seront très supérieurs à 
celui d’une opération de déplacement d’un std : ; s tri ng. 

Il est intéressant de noter que, si l’ancien mot de passe est plus court que le 
nouveau, il est généralement impossible d’éviter l’allocation-désallocation au cours de 
l’affectation et, dans ce cas, le passage par valeur affiche la même vitesse d’exécution 
que le passage par référence. Le coût de la copie d’un paramètre par affectation peut 
donc dépendre de la valeur des objets concernés par l’affectation ! Ce type d’analyse 
vaut pour tous les types de paramètres qui contiennent des valeurs stockées dans une 
mémoire allouée dynamiquement. Tous les types ne sont pas concernés, mais ils sont 
nombreux, notamment std: : string et std: :vector. 

En général, cette augmentation potentielle du coût s’applique uniquement lors 
du passage d’arguments lvalue, car l’allocation et la désallocation de la mémoire sont 
habituellement nécessaires uniquement pour les véritables opérations de copie (en 
dehors des déplacements). Pour les arguments rvalue, les déplacements font quasiment 
toujours l’affaire. 

Par conséquent, le coût supplémentaire du passage par valeur pour les fonctions qui 
copient un paramètre par affectation dépend du type du paramètre passé, du rapport 
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entre le nombre d’arguments lvalue et rvalue, de l’utilisation de la mémoire allouée 
dynamiquement par le type et, le cas échéant, de l’implémentation des opérateurs 
d’affectation du type et de la probabilité que la mémoire associée à la cible de 
l’affectation soit au moins aussi vaste que celle associée à la source de l’affectation. 
Pour un std : : st ri ng, il dépend également de l a mise en œuvre d e l’optimisation des 
petites chaînes (SS O, small string optimizadon ; voir le conseil 29) et de la possibilité 
de placer les valeurs affectées dans le tampon SSO. 

Nous l’avions dit, lorsque des paramètres sont copiés par affectation, l’analyse du 
coût du passage par valeur est complexe. Habituellement, l’approche la plus pratique 
consiste à adopter la surcharge ou les références universelles, et d’employer le passage 
par valeur uniquement s’il est démontré que le code obtenu se révèle efficace avec le 
type de paramètre concerné. 

Lorsque le logiciel doit s’exécuter le plus rapidement possible, le passage par valeur 
ne sera probablement pas une stratégie viable, car les déplacements même bon marché 
devront certainement être évités. Par ailleurs, il n’est pas toujours facile de connaître 
le nombre de déplacements impliqués. Dans l’exemple de Wi dget : : addName, un passage 
par valeur ne comprend qu’une seule opération de déplacement supplémentaire. 
Mais supposons que Wi dget : : addName ait appelé Wi dget : : val idateName et que cette 
fonction utilise également le passage par valeur. (On peut imaginer qu’elle a une 
bonne raison de toujours copier son paramètre, par exemple pour le stocker dans 
une structure de données qui contient toutes les valeurs validées.) Et supposons que 
val idateName ait appelé une troisième fonction qui utilise également le passage par 
valeur... 

Vous comprenez où cela nous mène. Lorsque nous sommes en présence d’une 
chaîne d’appels de fonctions, chacune employant le passage par valeur car « il ne coûte 
qu’un déplacement supplémentaire », le prix total des appels peut ne pas être tolérable. 
Avec un passage de paramètres par référence, les chaînes d’appels ne conduisent pas à 
cette accumulation d’un surcoût. 

Il existe un autre problème, sans lien avec les performances, qu’il est bon de ne 
pas oublier. Contrairement au passage par référence, le passage par valeur est sujet au 
problème de slicing. Puisque ce sujet a été largement traité en C++98, nous n’allons 
pas nous y attarder. Sachez simplement que si une fonction accepte un paramètre 
dont le type est une classe de base ou tout type qui en dérive, il ne faut pas déclarer un 
paramètre de ce type passé par valeur car cela « couperait » les caractéristiques de la 
classe dérivée pour tout objet de type dérivé passé : 

class Widget I ... 1; // Classe de base. 

class Speci alWîdget: public Widget { ... }; // Classe dérivée 

void processWidget(Widget w ) ; // Fonction pour tout type de Widget, 

// y compris les types dérivé ; 

// problème de slicing. 


SpecialWidget sw; 
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I processWidget(sw); Il processWidget voit un Widget, 

Il non un Speci a 1 Wi dget ! 

Si vous n’êtes pas familier de ce problème, les moteurs de recherche et Internet 
vous fourniront toutes les informations nécessaires. Vous découvrirez que l’existence 
de ce problème explique en partie (avant même les questions d’efficacité) la mauvaise 
réputation du passage par valeur en C++98. Ce n’est pas sans raison que l’une des 
premières choses que vous avez probablement apprises sur la programmation en C+ + 
était d’éviter de passer par valeur un objet de type défini par l’utilisateur. 

C++ 1 1 n’apporte aucun changement fondamental à cet égard. De façon générale, 
le passage par valeur entraîne une baisse des performances et peut toujours conduire 
au problème de slicing. En revanche, la nouveauté de C++ 1 1 réside dans la distinction 
entre les arguments lvalue et rvalue. L’implémentation de fonctions qui tirent profit 
de la sémantique de déplacement pour les rvalues de type copiable impose la surcharge 
ou les références universelles, mais ces deux approches ont des inconvénients. Pour 
le cas particulier où des types copiables, au déplacement bon marché, sont passés à 
des fonctions qui en effectuent toujours une copie, et où le problème de slicing est 
absent, un passage par valeur peut représenter une alternative facile à mettre en place 
et pratiquement aussi efficace que les approches par référence, sans souffrir de leurs 
inconvénients. 


À retenir 

• Pour les paramètres copiables, peu coûteux à déplacer et toujours copiés, 
le passage par valeur peut être quasiment aussi efficace que le passage par 
référence, il est plus facile à implémenter et il peut générer un code objet plus 
concis. 

• La copie des paramètres par construction peut être beaucoup plus coûteuse 
que leur copie par affectation. 

• Le passage par valeur souffre du problème de slicing et ne convient donc pas 
aux paramètres dont le type est une classe de base. 


CONSEIL N° 42. ENVISAGER LE PLACEMENT PLUTÔT 
QUE L'INSERTION 

Supposons que nous ayons un conteneur de std:: string. Il semblerait logique 
que le type d’un objet ajouté et passé à une fonction d’insertion (c’est-à-dire 
insert, push_front, push_back ou, pour std: :forward_list, insert_after) soit un 
std::string. C’est en effet le type des éléments du conteneur. 

Aussi logique que cela puisse être, ce n’est pas toujours vrai. Prenons le code 
suivant : 
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I std: :vector<std: :string> vs; Il Conteneur de std : : s tr i ng . 

vs.push_back("xyzzy") ; Il Ajouter une chaîne littérale. 

Le conteneur mémorise des std: :string, mais nous avons une chaîne de caractères 
littérale, c’est-à-dire une suite de caractères placés entre guillemets, que nous passons 
à push_back. Une chaîne littérale n’est pas un std: : string et l’argument que nous 
passons à push_back n’a donc pas le même type que les éléments du conteneur. 

La méthode push_back de std: : vector est surchargée pour les lvalueset les rvalues : 


template <class T, // Du C++11 standard. 

class Allocator = al 1 ocator<T>> 
class vector I 
publ ic: 


void push_back(const T& x ) ; 
void push_back( T&& x); 


// Insérer une lvalue. 
// Insérer une rvalue. 


Avec l’appel 


vs.push_back("xyzzy”) ; 

le compilateur détecte une incohérence entre le type de l’argument (const char [6]) 
et le type du paramètre pris par push_back (une référence àunstd::string). Il résout 
ce problème en générant du code qui crée un objet std : : string temporaire à partir 
de la chaîne littérale, puis en passant cet objet temporaire à push_back. Autrement 
dit, il fait comme si l’appel avait été écrit de la manière suivante : 


| vs.push_back(std: :string("xyzzy")) ; // Créer un std : : st r i ng temporaire 

// et le passer à push_back. 

Le code compile et s’exécute, tout le monde est satisfait. Tout le monde, à 
l’exception du mordu des perfonnances car il sait que ce code n’est pas aussi efficace 
qu’il le devrait. 

Pour créer un nouvel élément dans un conteneur de std : : stri ng, un constructeur 
de std : : stri ng doit évidemment être invoqué, mais le code précédent en appelle non 
pas un mais deux, sans mentionner l’invocation du destructeur de std : : stri ng. Voici 
ce qui se produit à l’exécution lors de l’appel à push_back : 

1. Un objet std : : stri ng temporaire est créé à partir de la chaîne littérale "xyzzy" ; 
il n’a pas de nom, alors appelons-le temp. La construction de temp correspond à la 
première construction d’un std : : stri ng. Puisqu’il s’agit d’un objet temporaire, 
temp est une rvalue. 
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2. temp est passé à la surcharge de push_back pour les rvalues, où il est lié au 
paramètre x de type référence rvalue. Une copie de x est ensuite construite 
en mémoire pour le std: :vector. Cette construction, la seconde, correspond 
à la création d’un nouvel objet dans le std: :vector. (Le constructeur utilisé 
pour copier x dans le std: :vector est le constructeur de déplacement car x, 
étant une référence rvalue, est converti en rvalue avant d’être copié. Pour de 
plus amples informations sur la conversion en rvalues des paramètres de type 
référence rvalue, consultez le conseil 25.) 

3. Immédiatement après le retour de push_back, temp est détruit, ce qui invoque 
le destructeur destd::string. 

Le mordu de performances remarque que s’il était possible de prendre la chaîne 
littérale et de la passer directement au code de l’étape 2 qui construit l’objet 
std : : stri ng dans le std : : vector, la construction et la destruction de temp seraient 
évitées. L’efficacité serait maximale, et ce fanatique des performances serait satisfait. 

Puisque vous êtes un programmeur C+ + , il y a de fortes chances que vous soyez 
obsédé par les performances. Et si ce n’est pas le cas, vous leur accordez certainement 
une petite attention. Nous sommes donc heureux de vous annoncer qu’une solution 
permet d’obtenir une efficacité maximale lors de l’appel à push_back. En réalité, il ne 
s’agit pas d’un appel à push_back ; cette fonction n’est pas la bonne, il faut utiliser 
empl ace_back. 

empl ace_back réalise exactement ce que nous souhaitons : elle se sert des arguments 
passés pour construire un std : : stri ng directement dans le std : : vector. Plus aucun 
objet temporaire n’intervient : 

| vs.emplace_back("xyzzy”): // Construire un std::string directement 

// dans vs à partir de "xyzzy". 

empl ace_back se fonde sur la transmission parfaite et, tant que nous évitons ses 
limitations (voir le conseil 30), nous pouvons passer à empl ace_back n’importe quel 
nombre d’arguments avec n’importe quelle combinaison de types. Par exemple, si nous 
souhaitons créer un std : : stri ng dans vs via le constructeur de std : : string qui prend 
un caractère et un nombre de répétitions, voici ce que nous devons écrire : 

| vs.emplace_back(50, 'x'): // Insérer un std : : s t ri ng constitué 

// de 50 caractères 'x'. 

emplace_back est disponible avec tous les conteneurs standard qui prennent en 
charge push_back. De même, tous les conteneurs standard qui prennent en charge 
push_f ront disposent de empl ace_f ront. Et tous ceux qui offrent i nsert (c’est-à-dire 
tous les conteneurs sauf std : : forward_l i st et std : : array) reconnaissent empl ace. Les 
conteneurs associatifs proposent empl ace_hi nt pour compléter leurs fonctions i nsert 
qui prend un itérateur « indice », et std: : forward_l i st apporte empl ace_after pour 
aller avec i nsert_after. 

Les fonctions de placement sont plus efficaces que les fonctions d’insertion car elles 
disposent d’une interface plus souple. Les fonctions d’insertion prennent des objets à 


Copyright © 2016 Dunod. 



Chapitre 8. Finitions 


insérer, tandis que les fonctions de placement prennent des arguments de construction 
des objets à insérer. Cette différence leur permet d’éviter la création et la destruction 
d’objets temporaires, dont les fonctions d’insertion peuvent avoir besoin. 

Puisque nous pouvons passer à une fonction de placement un argument du type 
des éléments du conteneur (la fonction effectue alors une construction par copie ou 
déplacement), le placement peut être employé même lorsqu’une fonction d’insertion 
n’a pas besoin d’un objet temporaire. Dans ce cas, l’insertion et le placement réalisent 
fondamentalement la même opération. Prenons par exemple ce code : 

std::string queenOfOisco( "Donna Summer"); 

Les deux appels suivants sont valides et mènent au même résultat sur le conteneur : 

vs . push_back( queenOf Di sco ) ; // Construire par copie queenOfDisco 

// à la fin de vs. 

vs . empl ace_back( queenOf Di sco ) ; // Idem. 

Les fonctions de placement ont donc les mêmes utilisations que les fonctions 
d’insertion, mais elles travaillent parfois plus efficacement et, tout au moins en théorie, 
ne devraient jamais être moins efficaces. Dans ce cas, pourquoi ne pas les employer 
systématiquement ? 

Parce que, si en théorie il n’y a pas de différence entre la théorie et la pratique, en 
pratique il y en a une. Avec les implémentations actuelles de la bibliothèque standard, 
il existe des situations dans lesquelles le placement est plus rapide que l’insertion mais, 
malheureusement, il en existe d’autres où les fonctions d’insertion sont plus efficaces. 
Ces cas ne sont pas faciles à caractériser car ils dépendent du type des arguments passés, 
des conteneurs employés, des emplacements dans le conteneur où se fait l’insertion 
ou le placement, de la sûreté vis-à-vis des exceptions des constructeurs des types 
contenus, et, pour les conteneurs qui interdisent les doublons (c’est-à-dire std : : set, 
std: :map, std: : unordered_set, std: : unorderedjnap), du fait que la valeur ajoutée 
est, ou non, déjà présente. Le conseil habituel sur les performances s’applique donc : 
pour déterminer qui du placement ou de l’insertion est le plus rapide, il faut les tester. 

Cette conclusion est évidemment peu satisfaisante et vous serez content d’ap- 
prendre qu’une heuristique peut aider à identifier les situations dans lesquelles les 
fonctions de placement ont toutes les chances de convenir. Si les conditions suivantes 
sont vérifiées, le placement sera presque à coup sûr plus efficace que l’insertion : 

• La valeur à ajouter est non pas affectée mais construite dans le conteneur. 

L’exemple donné au début de ce conseil (ajouter un std: : string de valeur 
"xyzzy" à un std: :vector) a montré l’ajout d’une valeur à la fin de vs — un 
emplacement où il n’existe encore aucun objet. La nouvelle valeur doit donc 
être construite dans le std : : vector. Si nous modifions l’exemple de sorte que 
le nouveau std : : st ri ng aille dans un emplacement déjà occupé par un objet, 
l’histoire est différente. Prenons le code suivant : 
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std: :vector<std: :string> v s ; // Comme précédemment. 

// Ajouter des éléments à vs. 

vs . empl ace(vs.begin( ) , "xyzzy"); // Ajouter "xyzzy” au 

II début de vs. 

Pour ce code, peu d’implémentations construiront le std : : st ri ng ajouté dans la 
zone de mémoire occupée par vs [0]. Elles effectueront plutôt une affectation par 
déplacement de la valeur à sa place. Mais l’affectation par déplacement a besoin 
d’un objet à déplacer. Autrement dit, un objet temporaire doit être créé pour 
servir de source au déplacement. Puisque le principal avantage du placement par 
rapport à l’insertion réside dans l’absence de création et de destruction d’objets 
temporaires, l’ajout de la valeur dans le container via une affectation remet en 
question l’intérêt du placement. 

Malheureusement, l’ajout par construction ou par affectation d’une valeur au 
conteneur est généralement un choix laissé aux développeurs. Cependant, une 
fois encore, une heuristique peut nous aider. Les conteneurs orientés noeuds 
utilisent pratiquement toujours la construction pour ajouter de nouvelles valeurs 
et la plupart des conteneurs standard s’articulent autour des nœuds. Les seules 
exceptions sont std : : vector, std::deque et std::string. (std::array fait 
également exception, mais il ne prend pas en charge l’insertion ou le placement, 
et ne nous intéresse donc pas.) Avec les conteneurs qui ne sont pas basés 
sur des nœuds, nous pouvons compter sur empl ace_back pour employer une 
construction à la place de l’affectation afin de placer la nouvelle valeur. Il en va 
de même pour empl ace_f ront de std: :deque. 

• Le ou les types des arguments passés diffèrent de celui des éléments du 
conteneur. Rappelons que l’avantage du placement par rapport à l’insertion 
découle généralement du fait que son interface ne nécessite aucune création et 
destruction d’un objet temporaire lorsque les arguments passés sont d’un type 
autre que celui des éléments du conteneur. Lorsqu’un objet de type T doit être 
ajouté à un conta iner< T>, il n’y a aucune raison de supposer que le placement 
sera plus rapide que l’insertion, car aucun objet temporaire n’a besoin d’être 
créé pour satisfaire l’interface d’insertion. 

• Le conteneur ne devrait pas refuser la nouvelle valeur sous prétexte qu’elle 
forme un doublon. Autrement dit, soit le conteneur accepte les doublons, soit 
la plupart des valeurs ajoutées seront uniques. Ce point est important car, pour 
détecter qu’une valeur se trouve déjà dans le conteneur, les implémentations 
du placement créent souvent un nœud avec cette valeur afin de la comparer 
aux nœuds existants dans le conteneur. Si la valeur ajoutée est absente du 
conteneur, le nœud est lié aux autres. En revanche, si la valeur est déjà présente, 
le placement est annulé et le nœud est détruit, gaspillant alors sa construction 
et sa destruction. De tels nœuds sont plus souvent créés par les fonctions de 
placement que celles d’insertion. 
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Les appels suivants, déjà présentés dans ce conseil, satisfont à tous les critères 
précédents. Ils s’exécutent plus rapidement que les appels correspondant à push_back. 

vs . empl ace_back ( "xyzzy " ) ; // Construire une nouvelle valeur à la fin 

// du conteneur ; le paramètre n’est pas 
// du type des éléments du conteneur ; 

// le conteneur ne refuse pas les doublons. 

vs .empl ace_back(50, 'x'); // Idem. 

Avant de décider d’utiliser les fonctions de placement, deux autres problèmes 
doivent être pris en compte. Le premier concerne la gestion des ressources. Supposons 
que nous ayons un conteneur de std : : shared_ptr<Wi dget> : 

std: : 1 i st<s td : : shared_ptr<Widget>> ptrs; 

Nous voulons ajouter un std : : shared_ptr dont la libération se fera à l’aide d’un 
supprimeur personnalisé (voir le conseil 19). Le conseil 21 explique que nous devons 
utiliser autant que possible std: :make_shared pour créer des std: :shared_ptr, mais 
il note également que certaines situations nous en empêchent, notamment lorsque 
nous voulons spécifier un supprimeur personnalisé. Dans ce cas, nous devons employer 
directement new pour obtenir le pointeur brut qui sera géré par le std : : shared_ptr. 

Supposons que la fonction suivante serve de supprimeur personnalisé : 

void kil lWidget(Widget* pWidget); 

Le code fondé sur une fonction d’insertion peut s’écrire ainsi : 

ptrs .push_back( std: :shared_ptr<Widget>(new Widget , kil 1 Widget) ) ; 

Voici une autre possibilité équivalente : 

ptrs .push_back( | new Widget, killWidget 1); 

Dans les deux versions, un std: :shared_ptr temporaire doit être construit 
avant l’appel à push_back. Puisque le paramètre de push_back est une référence à 
un std: :shared_ptr, il doit exister un std: :shared_ptr auquel ce paramètre fera 
référence. 

La création de ce std: :shared_ptr temporaire serait évitée avec empl ace_back, 
mais, dans ce cas, les bénéfices qu’il apporte outrepassent largement ses coûts. 
Examinons la séquence d’événements suivante : 

1. Dans les appels précédents, un objet std: :shared_ptr<Widget> temporaire est 
construit de façon à mémoriser le pointeur brut renvoyé par « new Widget ». 
Nommons temp cet objet. 
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2. push_back prend temp par référence. Pendant l’allocation d’un nœud de liste 
pour stocker une copie de temp , une exception signalant un manque de mémoire 
est levée. 

3. L’exception se propage hors de push_back et temp est détruit. Puisqu’il s’agit du 
seul std : : sharecLptr qui fait référence au Wi dget dont il a la charge, il libère 
automatiquement ce Wi dget en invoquant dans ce cas ki 1 1 Wi dget. 

Malgré l’exception, nous ne constatons aucune fuite de mémoire : le W i dget 
créé par « new Widget » dans l’appel à push_back est libéré par le destructeur de 
std: : shared_ptr, qui avait été créé pour le gérer ( temp). Tout va bien. 

Examinons à présent ce qui se passe si nous appelons empl ace_back à la place de 
push_back : 

ptrs.emplace_back(new Widget, ki 1 1 Wi dget ) ; 

1. Le pointeur brut obtenu par « new Widget » est transmis de façon parfaite à 
l’endroit de empl ace_back où un nœud de liste doit être alloué. Cette allocation 
échoue et une exception liée à un manque de mémoire est lancée. 

2. L’exception se propage en dehors de empl ace_back et le pointeur brut, qui était 
la seule manière d’accéder au Wi dget sur le tas, est perdu. Ce Wi dget (et toutes 
ses ressources) représente une fuite de mémoire. 

Dans ce scénario, rien ne va plus et la faute n’incombe pas à std: :shared_ptr. 
Le même type de problème peut survenir en cas d’utilisation de std: :unique_ptr 
et d’un supprimeur personnalisé. Fondamentalement, l’efficacité des classes de ges- 
tion de ressources, comme std: :shared_ptr et std: :unique_ptr, se fonde sur des 
ressources (comme les pointeurs bruts fournis par new) transmises immédiatement 
aux constructeurs des objets de gestion. Les fonctions comme std: :make_shared et 
std: :make_unique y procèdent de façon automatique et c’est l’une des raisons pour 
lesquelles elles sont si importantes. 

Dans les appels aux fonctions d’insertion des conteneurs qui stockent des objets 
de gestion de ressources (par exemple std: :list<std: :shared_ptr<Widget>>), les 
types des paramètres des fonctions permettent généralement de garantir que rien 
n’intervient entre l’acquisition d’une ressource (par exemple une utilisation de new) 
et la construction de l’objet qui gère cette ressource. Dans les fonctions de placement, 
la transmission parfaite reporte la création des objets de gestion de ressources jusqu’à 
leur construction dans la mémoire du conteneur et, pendant ce temps, des exceptions 
peuvent être levées et conduire à des fuites de ressources. Tous les conteneurs standard 
sont sujets à ce problème. Lorsque des conteneurs d’objets de gestion de ressources 
sont employés, l’utilisation d’une fonction d’emplacement à la place de sa version 
d’insertion doit se faire avec prudence, car la meilleure efficacité du code obtenue 
risque de coûter une sûreté moindre vis-à-vis des exceptions. 

Il est préférable d’éviter de passer des expressions comme « new Widget » à 
empl ace_back ou à push_back, voire même à n’importe quelle autre fonction, car, 
le conseil 2 1 l’explique, cela ouvre la porte à des problèmes de sûreté vis-à-vis des 
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exceptions, comme celui que nous venons de décrire. Pour fermer cette porte, nous 
devons transformer dans une instruction indépendante le pointeur fourni par « new 
Widget » en un objet de gestion de ressources. Celui-ci doit ensuite être transmis 
comme une rvalue à la fonction à laquelle nous voulions à l’origine passer « new 
Widget ». (Le conseil 21 détaille cette technique.) Voici donc comment écrire le code 
qui utilise push_back : 

std: :shared_ptr<Widget> spwinew Widget, // Créer un Widget qui sera 

killWidget); // géré par spw. 

ptrs .push_back(std: :move(spw) ) ; // Ajouter spw comme une rvalue. 

La version fondée sur empl ace_back est comparable : 

I std::shared_ptr<Widget> spwinew Widget, killWidget); 
ptrs .empl ace_back(std: :move(spw) ) ; 

Dans les deux cas, nous avons les coûts de création et de destruction de spw. Le 
choix du placement à la place de l’insertion était motivé par l’absence du coût de 
création d’un objet temporaire du type des éléments du conteneur. Bien que spw le soit 
conceptuellement, les fonctions de placement auront du mal à surpasser les fonctions 
d’insertion lorsque nous ajoutons des objets de gestion de ressources à un conteneur en 
suivant l’approche qui garantit que rien n’intervient entre l’acquisition d’une ressource 
et sa conversion en un objet de gestion de ressources. 

L’autre aspect problématique des fonctions de placement concerne leur interaction 
avec les constructeurs expli ci t. Pour rendre honneur à la prise en charge des 
expressions régulières dans C+ + 1 1, supposons que nous créions un conteneur d’objets 
d’expressions régulières : 

std: :vector<std: :regex> regexes; 

Distrait par les querelles de nos collègues sur le nombre idéal de consultations 
quotidiennes du compte Facebook d’un ami, nous écrivons par mégarde le code 
suivant : 

I regexes. empl ace_back(nul 1 ptr) ; // Ajouter nullptr au conteneur 

// d’expressions régulières ? 

Nous ne remarquons pas notre erreur pendant la saisie et le compilateur accepte 
ce code sans broncher. Nous perdons alors beaucoup de temps à son débogage. À 
un moment donné, nous découvrons que nous avons inséré un pointeur nul dans 
notre conteneur d’expressions régulières. Mais comment est-ce possible ? Puisque les 
pointeurs ne sont pas des expressions régulières, le compilateur n’accepte pas le code 
suivant : 


std: :regex r = nullptr; 


// Erreur ! Échec de la compilation. 
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Il est intéressant de noter que la compilation échoue également si nous remplaçons 
empl ace_back par push_back : 

regexes .push_back(nul 1 ptr) ; // Erreur ! Échec de la compilation. 

Le curieux comportement auquel nous sommes confrontés vient du fait que les 
objets std : : regex peuvent être construits à partir de chaînes de caractères. C’est pour 
cette raison que nous pouvons écrire le code utile suivant : 

std: :regex upperCaseWord("[A-Z]+") ; 

La création d’un std : : regex à partir d’une chaîne de caractères peut avoir un coût 
élevé. De façon à réduire la probabilité qu’une telle dépense soit faite par mégarde, le 
constructeur de std: : regex qui prend un pointeur const char* est déclaré expl ici t. 
Voilà pourquoi la compilation des lignes suivantes échoue : 

std::regex r = nul 1 ptr ; // Erreur ! Échec de la compilation, 

regexes .pus h_b a c k ( n u 1 1 ptr) ; // Erreur ! Échec de la compilation. 

Dans les deux cas, nous demandons une conversion implicite depuis un pointeur 
vers un std : : regex, mais la déclaration expl i ci t de ce constructeur l’empêche. 

En revanche, dans l’appel à empl ace_back, nous ne prétendons pas passer un objet 
std : : regex. À la place, nous passons un argument de construction d’un objet std : : regex. 
Cela ne constitue pas une demande de conversion implicite mais équivaut au code 
suivant : 

std::regex r(nullptr); Il Réussite de la compilation. 

Si la réussite de la compilation ne soulève pas chez vous un grand enthousiasme, 
vous avez raison car ce code affiche un comportement indéfini. Le constructeur de 
std : : regex qui prend un pointeur const char* exige que la chaîne désignée représente 
une expression régulière valide, ce qui n’est pas le cas d’un pointeur nul. Si nous 
écrivons et compilons un tel code, le mieux que nous puissions espérer est un plantage 
du programme à l’exécution. Si nous manquons de chance, nous allons passer beaucoup 
de temps auprès de notre débogueur. 

Mettons un instant de côté push_back, empl ace_back et le débogueur pour noter 
combien des syntaxes d’initialisation très proches conduisent à des résultats différents : 

std::regex rl = nul 1 ptr; // Erreur ! Échec de la compilation. 

std::regex r2(nullptr); // Réussite de la compilation. 

Selon la terminologie officielle de la norme, la syntaxe employée pour initialiser 
rl (avec le signe égal) correspond à une initialisation par copie. À l’opposé, la syntaxe 
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d’initialisation de r2 (avec les parenthèses, qui peuvent aussi être remplacées par 
des accolades) correspond à une initialisation directe. L’initialisation par copie ne peut 
pas se servir des constructeurs expl i ci t ; l’initialisation directe y est autorisée. C’est 
pourquoi le code d’initialisation de rl ne compile pas, contrairement à celui de r2. 

Revenons à push_back et à empl ace_back, et, plus généralement, à la comparaison 
entre les fonctions d’insertion et les fonctions de placement. Puisque les fonctions 
de placement se fondent sur l’initialisation directe, elles peuvent employer les 
constructeurs expli ci t. Ce n’est pas le cas des fonctions d’insertion qui utilisent 
l’initialisation par copie. Nous avons donc les comportements suivants : 


regexes .empl ace_back(nul 1 ptr) ; // Réussite de la compilation. 

// L’initialisation directe autorise 
// l’utilisation du constructeur 
// expli ci t de std::regex qui 
// prend un pointeur. 

regexes ,push_back(nul 1 ptr) ; // Erreur ! L’initialisation par copie 

// interdit ce constructeur. 

En conclusion, lorsque nous utilisons une fonction de placement, il faut faire 
particulièrement attention à passer des arguments corrects, car même les construc- 
teurs expli ci t seront examinés par le compilateur lorsqu’il essaiera de trouver une 
interprétation valide de notre code. 


À retenir 

• En principe, les fonctions de placement sont plus efficaces que les fonctions 
d'insertion équivalentes, mais elles ne devraient jamais être moins efficaces. 

• En pratique, elles seront plus rapides lorsque (1) la valeur ajoutée est non pas 
affectée mais construite dans le conteneur, (2) les types des arguments passés 
diffèrent du type des éléments du conteneur, et (3) le conteneur ne refuse pas 
les doublons ajoutés. 

• Les fonctions de placement peuvent effectuer des conversions de type qui 
seraient rejetées par les fonctions d'insertion. 
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déclaration 5 
déclaration d’alias 62 
définition 5 

demande excédentaire 239 
durée de stockage statique 218 
élision de copie 170 
entrées-sorties mappées en mémoire 

770 

enum délimités 67 
enum non délimités 67 
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sémantique du déplacement 153 
signature d’une fonction 6 
small string optimization (SSO) 199 
std: : thread joignable 246 
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std : :weak_ptr périmé 132 


stockages morts 271 

supprimeur personnalisé 118 
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template inactif 184 
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TLS ( thread local storage) 243 
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type dépendant 64 

type incomplet 145 
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destructeurs 

lien avec les opérations de copie et 
la gestion de ressources 108 
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déclaration anticipée 68 
délimités contre enum non délimités 
67 

délimités, définition 67 
dépendances de compilation et 69 
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67 
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std: :tuples et 71 
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errata 7 
état partagé 

compteur de références dans 254 
définition 254 

futur, comportement du destructeur 

254 

exceptions 
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Base 78, 110 
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Investment 117, 120 
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Password 282, 283 
Pe r son T7T, 178, 780, 784, 786, 788, 
190 


Poi nt 24, 98, 100, 103 

Polynomial 101 
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std: : remove_reference 65 
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ThreadRAI I 249, 252 
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204,215,220, 255,275,284 
Widget: : Impi 146, 149 
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Base: :Base 110 
Base: :~Base 110 
Base: :doWork 78 
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Deri ved: :mf3 80 
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ThreadRAII: :ThreadRAII 249 
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Widget: :processWidget 137 
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Wi dget : : setPtr 280 
Widget: : Widget 3, 52, 107, 109, 112, 
145,151,158,164 
Widget: : —Wi dget 109, 145, 148 
workOnVal 207 
workWi thContainer 214 
expressions constantes entières, 
définition 95 
expressions lambda 

arguments liés et déliés 233 
capture avec une durée de stockage 
statique 218 
capture généralisée 219 
capture implicite du pointeur this 

IT6 

capture, modes par défaut 212 
capture par déplacement 234 
capture par référence 213 
capture par valeur, inconvénients 

ITT 

capture par valeur, pointeurs et 2 1 5 

code inline et 231 

contre std: : b i n d 228 

définition 5, 21 1 

fermetures, créer 212 

objets fonctions polymorphiques et 

234 

paramètres auto&& et decltype 225 
puissance d’expression 211 
références dans le vide et 213 
surcharge et 230 
variadiques 227 

expressions lambda contre std: : b i n d 
arguments déliés, traitement 234 
arguments liés, traitement 233 


Copyright © 2016 Dunod. 



Programmer efficacement en C++ 
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code inline et 23 1 
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objets fonctions polymorphiques et 
234 

surcharge et 230 
expressions lambda génériques 
définition 225 

operator( ) 225 

F 

fermetures 

classe de fermeture, définition 212 
copies 212 
définition 5, 212 
fi nal , mot clé 81 
fonctionnalités obsolètes 
définition 6 

génération automatique d’une 
opération de copie 109 
spécifications d’exceptions en 
C++9888 
std : : auto_ptr 1 16 
fonctions 

arguments, définition 4 
déduction de type de retour 25 
dégradation 17 
fabriques avec cache 133 
gourmandes en C++ 175 
noexcept conditionnel 91 
noms surchargés 206 
objets, définition 4 
paramètres, définition 4 
privées et indéfinies, contre 
fonctions supprimées 74 
références universelles et 175 
signature, définition 6 
syntaxes des paramètres de type 
pointeur 206 
virtuelles, override et 78 


fonctions make 
définition 136 
duplication du code et 137 
parenthèses contre accolades 140 
supprimeurs personnalisés 139 
sûreté vis-à-vis des exceptions 137, 
29l 

fonctions membres 86 
par défaut 109 

qualificatifs de référence et 82 
templates 1 1 2 

fonctions membres spéciales 
définition 106 
génération implicite 106 
template de fonction membre 112 
fonctions non membres 87 
suppression 75 
fonctions supprimées 73 

contre fonctions privées et 
indéfinies 74 
définition 74 

forwarding, références 160 
futurs 

comportement indéterminé du 
destructeur 255 

voi d 261 

G 

garantie forte 
définition 4 

noexcept et 90 

opérations de déplacement et 200 
garantie minimale, définition 4 
gestion de ressources 

opérations de copie et destructeur 

1Ô8 

suppression et 124 
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inférence de type Voir déduction de type 
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ordre avec des données membres 
std: :thread 250 
syntaxes 49 
uniforme 50 

initialiseurs à accolades 50 
auto et 21 

déduction de type de retour 23 
définition 50 

std: : i ni ti al i zer_l i sts et 53, 54 
transmission parfaite et 203, 204 
initialiseurs au type explicite 43 
insertion 

constructeurs expl i ci t et 293 
contre placement 285 
interface, conception 
constexpr et 100 

contrats étendus contre restreints 93 
spécifications d’exceptions 88 
interrogation, coût/efficacité 260 

J 

joignabilité, test sur std: :thread 250 

L 

lecture-modification-écriture, opérations 
266 

std: :atomic et 266 
volatile et 266 
1 hs, définition 3 
lvalues, définition 2 

M 

mauvaise odeur du code 258 
mémoire 

entrées-sorties mappées en mémoire 
27Ô 

locale de thread, définition 243 
modèles de cohérence 268 
spéciale 269 


messages d’erreur, références universelles 
et 190 

mise en exergue 3 
modes de capture par défaut 212 
most vexing parse, définition 5 1 
mots clés contextuels 81 
définition 81 

N 

named return value optimization (NRVO) 

T7Ô 

neutralité envers les exceptions, 
définition 92 

Newton, lois du mouvement 164 

noexcept 88 

avertissements du compilateur et 94 

conditionnel 91 

destructeurs et 92 

fonctions de désallocation et 92 

fonctions swap et 90 

garantie forte et 90 

interface de fonction et 91 

opérations de déplacement et 89 

operator del ete et 92 

optimisation et 88 

NRVO ( named return value optimization ) 
Voir optimisation de la valeur 
de retour nommée 

NULL 

surcharge et 58 
templates et 60 
nul 1 ptr 

contre 0 et NULL 58 
surcharge et 59 
templates et 60 
type 59 

O 

objets 

copie, définition 4 
création avec ( ) et {} 49 
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opérations de copie 
définition 3 

génération automatique 109 
idiome Pimpl et 150 
implicites dans les classes qui 
déclarent des opérations de 
déplacement 108 

lien avec le destructeur et la gestion 
de ressources 108 

par construction et par affectation, 
comparaison 281 
par défaut 110 

pour des classes qui déclarent des 
opérations de copie ou un 
destructeur 109 
pour std : : atomi c 272 
opérations de déplacement 
code générique et 201 
définition 3 
garantie forte et 200 
génération implicite 107 
idiome Pimpl et 149 
par défaut 110 
std : : array et 199 
std : : shared_ptr et 124 
std : : st ri ng et 199 
templates et 201 
types anciens et 198 

operatorO, dans les expressions lambda 
génériques 225 

operator[], type de retour 24, 46 
optimisation 

de la valeur de retour, définition 170 
des petites chaînes (SSO) 199, 283 
overri de 78 

comme mot clé 81 
conditions de redéfinition 78 
fonctions virtuelles 78 
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paramètres 

de type référence rvalue 2 
par valeur, std: :move 277 
transmission, définition 201 
passage par valeur 275 
efficacité 277 
problème de slicing 284 
Pimpl (idiome) 144 
définition 144 
opérations de copie et 150 
opérations de déplacement et 149 
std : : shared_ptr et 151 
std : : uni que_ptr et 146 
temps de compilation et 145 
placement 

constructeurs expl i ci t et 292 
construction contre affectation 288 
contre insertion 285 
fonctions 287 

heuristique pour l’utilisation 288 
sûreté vis-à-vis des exceptions 290 
transmission parfaite et 287 
pointeurs 

dans le vide Voir pointeurs 
pendouillant 
de retour 135 

pendouillant, définition 131 
pointeurs bruts 

comme pointeurs de retour 135 
définition 6 
inconvénients 115 
pointeurs intelligents 115 

contre pointeurs bruts 1 1 5 
définition 6, 1 16 

gestion d’une ressource à propriété 
exclusive 116 

pointeurs pendouillant et 131 
points de suspension 
étroits 3 
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multitâche, définition 238 
multithread, définition 237 
propriétaire d’une ressource, définition 

TTT 

propriété 

exclusive, définition 1 1 7 
partagée, définition 123 

Q 

qualificatifs de référence 
définition 79 

sur des fonctions membres 82 

R 

RAII 

classes, définition 248 
objets, définition 248 
réduction de référence 191 
auto et 196 
contextes 195 
déclarations d’alias et 196 
decl type et 197 
règles 193 
typedef et 196 
références 

à des références, illégalité 192 
aux tableaux 16 
dans le code binaire 205 
dans le vide 213 
fürwarding 160 
réduction 191 

référence Ivalues, définition 2 
références rvalue 

contre références universelles 160 
définition 2 

dernière utilisation 167 
paramètres 2 

passer à std: rforward 226 
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transmission parfaite, 160 

alternatives à la surcharge sur 179 
auto et 163 

avantages par rapport à la surcharge 

T66 

constructeurs et 175, 184 
contre références rvalue 1 60 
déduction de type et 161 
dernière utilisation 167 
efficacité 174 

encodage de lvalue/rvalue 192 
fonctions gournandes et 175 
forme syntaxique 161 
initialiseurs et 161 
messages d’erreur et 1 90 
noms 163 

signification réelle 196 
std: :move et 165 
surcharge et 173 
Règle des trois, définition 108 
relais Voir transmission parfaite 
répartition de charge 240 

Resource Acquisition is Inidalization 
Voir RAII 

ressources, gestion Voir gestion de 
ressources 

return value optimization (RVO) 170 
réveils intempestifs, définition 259 
rhs, définition 3 

RMW (read-modify -write ) , opérations 
Voir lecture-modification- 
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opérations 

rval ue_cast 155 

rvalues, définition 2 

RVO ( return value optimization ) 

Voir optimisation de la valeur 
de retour 
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shared_f rom_thi s 129 
signe égal (=), affectation contre 
initialisation 50 
slicing, problème 284 
SSO ( small string optimization) 

Voir optimisation des petites 
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stati c_assert 147, 191 
std: :add_l val ue_reference 65 
std: :add_l val ue_reference_t 66 
std: :allocate_shared 

classes avec gestion personnalisée de 
la mémoire 141 
efficacité 139 
std: : a 1 1 _of 214 

std: :array, opérations de déplacement 
etl99 

std: :async 240 

destructeur des futurs créés 254 
std: : packaged_task et 256 
stratégie de démarrage 242 
stratégie de démarrage, boucles 
temporisées 243 

stratégie de démarrage, mémoire 
locale de thread 243 
stratégie de démarrage par défaut 
242 

std: :atomi c 265 

chargements redondants et 271 
contre volatile 265 
opérations de copie et 272 
opérations de lecture- 

modification-écriture 266 
réorganisation du code et 267 
stockages morts et 27 1 
utilisation avec volatile 273 
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std: : b a s i c_ios 74 
std: :basic_ios: : ba s i c_i os 74 
std: : basi c_i os : :operator= 74 
std: : b i n d 

arguments liés et déliés 233 
captures par déplacement 234 
captures par déplacement, 
émulation 222 
code inline et 23 1 
contre expressions lambda 228 
lisibilité 228 

objets fonctions polymorphiques et 

' 234 

surcharge et 230 
transmission parfaite et 234 
std: :cbegin 87 
std: :cend 87 
std: :crbegin 87 
std: :crend 87 
std: :decay 185 
std: :enable_if 184 
std: :enabl e_shared_f rom_thi s 128 
std: : fa 1 se_type 182 
std: :forward 157, 193, 195 
conversion de type et 154 
références rvalue, passer à 226 
références universelles et 164 
remplacer std: :move par 158 
retour par valeur et 168 
std: :function 39 
std: :future<void> 261 
std: : ini ti al i zer_l i sts, initialiseurs à 
accolades et 53 
std: :is_base_of 187 
std: : i s_constructibl e 190 
std : : i s_nothrow_move_constructi bl e 
9T 
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utilisation automatique en stratégie 
de démarrage 245 
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std: :1 itérais 229 
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alternatives à 291 

classes avec gestion personnalisée de 
la mémoire 141 
efficacité 139 
objets volumineux et 141 
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std: :move 154 

conversion de type et 154 
objets const et 155 
paramètres par valeur et 277 
références rvalue et 1 64 
références universelles et 165 
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retour par valeur et 168 
std: :move_i f_noexcept 91 
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std: :operator 156 
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std: : rend 87 
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construction à partir de t h i s 127 
construction à partir d’un pointeur 
brut 126 

contre std: :weak_ptr 132 
conversion depuis std: :unique_ptr 
122 

création à partir d’un std: :weak_ptr 

132 

cycles et 134 
efficacité 123, 130 
opérations de déplacement et 124 
supprimeurs 124 

supprimeurs std : : uni que_ptr 152 
tableaux et 131 
taille 123 

std::string, opérations de déplacement 
et TW 
std : : swap 91 
std : : system_error 239 
std: :thread 

classe RA1I pour 249, 263 
comme données membres, ordre 
d’initialisation des membres 
"250 

join ou detach implicite 248 
non joignable, définition 246 
test de joignabilité 250 
std: :thread joignable 

contre non joignable 246 
définition 246 
destruction 246 
test de joignabilité 250 
std: :true_type 182 
std : : uni que_ptr 1 16 

conversion vers std: :shared_ptr 

T22 

efficacité 116 
fonctions fabriques et 1 1 7 
pour les tableaux 121 
supprimeurs 118, 124 
supprimeurs std: :shared_ptr 152 
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std: :vector<bool>: :reference 43 
std: : vector : :empl ace_back 162 
std: :vector: :push_back 162, 286 
std: :weak_ptr 

construction d’un std: :shared_ptr 
avec 132 

contre std : : shared_ptr 132 
cycles et 134 

design pattern Observateur et 134 
efficacité 135 

interception d’exception et 133 
périmé 132 

stockages morts, définition 271 
stratégie de démarrage par défaut 242 
mémoire locale de thread 243 
structures, exemples Voir exemples de 
c lasses/ temp la tes 
suffixes de temps 229 
suppression de fonctions Voir fonctions 
supprimées 
supprimeurs 

personnalisés 1 18, 139 
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surcharge 

alternatives à 179 
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expression lambda et 230 
références universelles et 166, 173 
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